¿Cuál es el sentido detrás de los límites de ZFS?


10

Según Wikipedia , ZFS tiene los siguientes límites:

  • Max. tamaño de volumen : 256 billones de yobibytes (2 128 bytes)
  • Max. tamaño de archivo : 16 exbibytes (2 64 bytes)
  • Max. cantidad de archivos :
    • Por directorio: 2 48
    • Por sistema de archivos: ilimitado
  • Max. longitud del nombre de archivo : 255 caracteres ASCII (menos para codificaciones de caracteres multibyte como Unicode)

¿Por qué tiene estos límites? ¿Qué limita internamente estas cosas? ¿Por qué ZFS no podría tener un tamaño de volumen teóricamente ilimitado, o longitud de nombre de archivo, y así sucesivamente?

Respuestas:


27

¿Qué limita internamente estas cosas?

Respuesta larga

Los límites de ZFS se basan en enteros de tamaño fijo porque esa es la forma más rápida de hacer aritmética en una computadora.

La alternativa se llama aritmética de precisión arbitraria , pero es inherentemente lenta . Esta es la razón por la cual la aritmética de precisión arbitraria es una biblioteca complementaria en la mayoría de los lenguajes de programación, no la forma predeterminada de hacer aritmética. Hay excepciones, pero por lo general son orientados matemáticas- DSL como bco Wolfram idioma .

Si desea una aritmética rápida, use palabras de tamaño fijo, punto.

El éxito de la velocidad de la aritmética de precisión arbitraria es suficientemente malo dentro de la RAM de una computadora, pero cuando un sistema de archivos no sabe cuántas lecturas debe hacer para cargar todos los números que necesita en la RAM, eso sería muy costoso. Un sistema de archivos basado en enteros de tamaño arbitrario tendría que juntar cada número de múltiples bloques, lo que requeriría una gran cantidad de E / S adicionales de múltiples golpes de disco en relación con un sistema de archivos que sabe de antemano qué tan grandes son sus bloques de metadatos.

Ahora analicemos la importancia práctica de cada uno de esos límites:

Max. tamaño de volumen

2 128 bytes ya es efectivamente infinito. En cambio, podemos escribir ese número como aproximadamente 10 38 bytes, lo que significa que para alcanzar ese límite, tendrías que tener un único grupo ZFS del tamaño de la Tierra donde cada uno de sus 10 50 átomos se usa para almacenar datos, y cada uno el byte es almacenado por un elemento no mayor de 10 12 átomos.

10 12 átomos suena mucho, pero son solo unos 47 picogramos de silicio .

La densidad de datos en gramos es 2.5 × 10 -13  g / byte para almacenamiento microSD, a partir de este escrito: la tarjeta SD más grande disponible es 1 TB, y pesa aproximadamente 0.25 g. Una tarjeta microSD no está hecha de puro silicio, pero no puede ignorar el empaque, porque también necesitaremos algo de eso en nuestra computadora de la Tierra; asumiremos que la baja densidad del plástico y la mayor densidad de los pines metálicos promedian aproximadamente la misma densidad que el silicio. También necesitamos un poco de descuido aquí para tener en cuenta las interconexiones entre chips, etc.

A pico- nada es 10 -12 , así que nuestra 47 pg y 2,5 × 10 -13  números g / B anteriormente son aproximadamente un orden de magnitud de diferencia. Eso significa que, para una primera aproximación, para construir un único conjunto ZFS de tamaño máximo a partir de las tarjetas microSD más grandes disponibles en la actualidad, es posible que tenga que usar átomos de un planeta entero del tamaño de la Tierra, y luego solo si comienza con algo cercano a la combinación correcta de silicio, carbono, oro, etc., de tal manera que no termine con tanta escoria que sople la estimación.

Si cree que es injusto que esté usando almacenamiento flash aquí en lugar de algo más denso como la cinta o el disco, considere las velocidades de datos involucradas, así como el hecho de que ni siquiera hemos tratado de considerar la redundancia o el reemplazo del dispositivo. Tenemos que suponer que este grupo ZFS del tamaño de la Tierra estará compuesto por vdevs que nunca necesitan ser reemplazados, y que pueden transferir datos lo suficientemente rápido como para que pueda llenar el grupo en un tiempo razonable. Solo el almacenamiento en estado sólido tiene sentido aquí.

La aproximación anterior es bastante aproximada, y las densidades de almacenamiento continúan subiendo, pero mantenga las cosas en perspectiva: en el futuro, para lograr este truco de construir piscinas ZFS de tamaño máximo, aún tendremos que usar la corteza total para ... recursos centrales de pequeños planetas .

Max. tamaño del archivo

Así que ahora tenemos un sistema de archivos del tamaño de un planeta . ¿Qué podemos decir sobre el tamaño de los archivos almacenados en él?

Démosle a cada persona en el planeta su propia porción del mismo tamaño:

10 38  ÷ 10 10  ≈ 10 28  ÷ 10 19  ≈ 10 9

Ese es el tamaño del grupo dividido por la población de la Tierra² dividido por el tamaño máximo del archivo, en números redondos.

En otras palabras, cada persona puede almacenar aproximadamente mil millones de archivos de tamaño máximo en su pequeña porción personal de nuestra matriz de almacenamiento ZFS del tamaño de la Tierra.

(Si le molesta que nuestra matriz de almacenamiento siga siendo del tamaño de un planeta aquí en este ejemplo, recuerde que tenía que ser tan grande para alcanzar el primer límite anterior, por lo que es justo continuar usándolo para este ejemplo aquí.)

Ese tamaño máximo de archivo por archivo es 16  EiB bajo ZFS, que es 16 veces más grande que el tamaño de volumen máximo de ext4 , que se considera ridículamente grande hoy en día por derecho propio.

Imagine a alguien usando su porción de Planet ZFS (anteriormente conocido como Tierra) para almacenar copias de seguridad de imágenes de disco ext4 de tamaño máximo. Además, este cliente demente (siempre hay uno) ha decidido tarsubirlos, 16 por archivo, solo para alcanzar el límite máximo de tamaño de archivo ZFS. Una vez hecho esto, ese cliente todavía tendrá espacio para hacerlo nuevamente unas mil millones de veces más.

Si va a preocuparse por este límite, ese es el tipo de problema que tiene que imaginar que necesita resolver. Y eso sin siquiera entrar en el ancho de banda de datos requerido para transferir ese archivo al servicio de respaldo en línea una vez .

También seamos claros acerca de lo improbable que es la computadora Tierra. Primero tendrías que descubrir cómo construirlo sin permitir que se derrumbe sobre sí mismo bajo la fuerza de la gravedad y se derrita en el centro. Entonces tendrías que descubrir cómo fabricarlo usando cada átomo de la Tierra sin restos de escoria.

Ahora, dado que ha convertido la superficie de la computadora de la Tierra en un infierno, todas las personas que intentan usar esa computadora tendrían que vivir en otro lugar, un lugar donde con frecuencia oiría a la gente maldecir la velocidad de ... retrasos leves que agregan latencia a cada transacción entre la computadora de la Tierra y donde sea que vivan ahora. Si cree que su tiempo de ping de Internet de ~ 10 ms es un problema hoy, imagine poner 2.6 segundos luz entre su teclado y la computadora si trasladamos la población de la Tierra a la Luna para que podamos hacer esta computadora de la Tierra.

Las limitaciones de volumen y tamaño de archivo de ZFS son grandes en ciencia ficción.

Max. cantidad de archivos por directorio

2 48 son aproximadamente 10 14 archivos por directorio, lo que solo será un problema para las aplicaciones que intentan tratar a ZFS como un sistema de archivos plano .

Imagine un investigador de Internet que está almacenando archivos sobre cada dirección IP en Internet. Digamos que se están rastreando exactamente 2 32 IP después de restar primero los espacios vacíos en el antiguo espacio IPv4 y luego agregar los hosts que ahora usan direcciones IPv6 para que la aritmética salga bien. ¡Qué problema está tratando de resolver este investigador que requiere que construya un sistema de archivo que pueda almacenar más de 2 16 - 65536! - archivos por IP?

Digamos que este investigador también está almacenando archivos por puerto TCP, de modo que con solo un archivo por combinación de IP: puerto, hemos consumido nuestro multiplicador 2 16 .

La solución es simple: almacene los archivos por IP en un subdirectorio con el nombre de la IP y almacene los archivos por puerto en un subdirectorio del directorio que contiene los archivos por IP. Ahora nuestro investigador puede almacenar 10 14 archivos por IP: combinación de puertos, suficiente para un sistema global de monitoreo de Internet a largo plazo.

El límite de tamaño de directorio de ZFS no es lo que yo llamaría "ciencia ficción grande", ya que hoy conocemos aplicaciones reales que pueden alcanzar este límite, pero el poder de la jerarquía significa que puede agregar otra capa de directorio si se encuentra con el límite.

Este límite probablemente se establece tan bajo como esto simplemente para evitar que las estructuras de datos necesarias para encontrar archivos en un directorio dado sean demasiado grandes para caber en la RAM. Lo alienta a organizar sus datos jerárquicamente para evitar este problema en primer lugar.

Max. longitud del nombre de archivo

Si bien este límite parece estricto, en realidad tiene sentido.

Este límite no se origina con ZFS. Creo que se remonta a FFS en 4.2BSD . No puedo encontrar la cita, pero cuando este límite era joven, alguien señaló que esto es suficiente espacio para "una breve carta a la abuela".

Entonces, eso plantea la pregunta: ¿por qué necesita nombrar sus archivos de manera más descriptiva que eso? Cualquier necesidad real mayor que eso probablemente requiera jerarquía, en cuyo punto multiplique el límite por el número de niveles en la jerarquía, más uno. Es decir, si el archivo está enterrado a 3 niveles de profundidad en la jerarquía, el límite en el nombre de la ruta completa es 4 × 255 = 1020 caracteres.

En última instancia, este límite es un límite humano, no un límite tecnológico. Los nombres de archivo son para uso humano, y los humanos realmente no necesitan más de 255 caracteres para describir útilmente el contenido de un archivo. Un límite superior simplemente no sería útil. La limitación es antigua (1983) porque los humanos no han adquirido la capacidad de hacer frente a nombres de archivo más largos desde entonces.

Si está preguntando de dónde proviene el valor "255" de aspecto extraño, es una limitación basada en el tamaño de un byte de 8 bits. 2 8 es 256, y el valor N-1 usado aquí probablemente significa que están usando un terminador nulo para marcar el final de la cadena del nombre del archivo en un campo de 256 bytes en los metadatos por archivo.

Respuesta corta

Hablando prácticamente, ¿qué límites?


Notas al pie:

  1. Medí esto usando una escala especificada con una precisión de 0.01g.

  2. 7,55 mil millones , a partir de este escrito. Arriba, estamos redondeando esto a 10 10 , que deberíamos alcanzar a mediados de siglo .


3
Lectura agradable, gracias! El número mínimo para PATH_MAXun sistema POSIX es 256. Puede estar compuesto por componentes de como máximo NAME_MAXcaracteres cada uno (este valor es al menos 14).
Kusalananda

2
Muy buena respuesta. Para agregar a la parte del nombre de archivo: los nombres de archivo largos en realidad disminuyen la usabilidad para los humanos, especialmente si se mezclan con nombres cortos (se necesita más tamaño de pantalla para mostrarlos, el diseño se verá afectado, el historial de shell será más difícil de leer, etc.), y aún son inferior a un sistema de etiquetado flexible y de búsqueda (que ZFS carece, desafortunadamente).
user121391

Eso es sorprendente, pero ¿por qué paralizaron el nombre del archivo a 255 caracteres? Hay casos de uso muy prácticos para eso, por ejemplo, cursos largos o títulos de libros o trabajos junto con la lista de nombres de autores. Y hay un software que se rompe cuando no puede escribir el nombre de archivo completo, por ejemplo, youtube-dlal descargar el video de dicho curso.
Dan Dascalescu el

@DanDascalescu Lo justifiqué en la respuesta y di remedios.
Warren Young, el

@WarrenYoung: no es necesario justificar, ya que no impusiste el límite. Sin embargo, no creo que tal como sea, la sección "Longitud máxima del nombre de archivo" aborde mi objeción (con el ejemplo del título "curso / libro / papel"). Quiero que mi nombre de libro / curso / video sea autosuficiente, no dividido artificialmente en un directorio (por ejemplo, el autor) más un nombre de archivo. Vea la regla de cero, uno, infinito y ejecute una búsqueda simple de ventanas "nombre de archivo demasiado largo" : revela decenas de millones de resultados.
Dan Dascalescu
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.