Qu'est-ce qui limite en interne ces choses?
Longue réponse
Les limites de ZFS sont basées sur des entiers de taille fixe car c'est le moyen le plus rapide de faire de l'arithmétique dans un ordinateur.
L'alternative est appelée arithmétique à précision arbitraire , mais elle est intrinsèquement lente . C'est pourquoi l'arithmétique à précision arbitraire est une bibliothèque complémentaire dans la plupart des langages de programmation, et non la manière par défaut de faire de l'arithmétique. Il y a des exceptions, mais ce sont généralement des DSL orientés mathématiques comme bcou Wolfram Language .
Si vous voulez une arithmétique rapide, vous utilisez des mots de taille fixe, point.
La vitesse atteinte par l'arithmétique de précision arbitraire est suffisamment mauvaise à l'intérieur de la RAM d'un ordinateur, mais lorsqu'un système de fichiers ne sait pas combien de lectures il doit effectuer pour charger tous les nombres dont il a besoin dans la RAM, ce serait très coûteux. Un système de fichiers basé sur des nombres entiers de taille arbitraire devrait reconstituer chaque nombre à partir de plusieurs blocs, nécessitant beaucoup d'E / S supplémentaires provenant de plusieurs hits de disque par rapport à un système de fichiers qui sait à l'avance la taille de ses blocs de métadonnées.
Voyons maintenant l'import pratique de chacune de ces limites:
Max. taille du volume
2 128 octets sont déjà en fait infinis. Nous pouvons plutôt écrire ce nombre à environ 10 38 octets, ce qui signifie que pour atteindre cette limite, vous devez avoir un seul pool ZFS de la taille de la Terre où chacun de ses 10 50 atomes est utilisé pour stocker des données, et chaque octet est stocké par un élément ne dépassant pas 10 12 atomes.
10 12 atomes, c'est beaucoup, mais ce n'est que 47 picogrammes de silicium .
La densité des données en grammes est de 2,5 × 10 -13 g / octet pour le stockage microSD, à ce jour: la plus grande carte SD disponible est de 1 To et pèse environ 0,25 g.¹ Une carte microSD n'est pas faite de pure du silicium, mais vous ne pouvez pas ignorer l'emballage, car nous en aurons également besoin dans notre ordinateur terrestre; nous supposerons que la faible densité du plastique et la densité plus élevée des broches métalliques atteignent en moyenne environ la même densité que le silicium. Nous avons également besoin d'une certaine pente ici pour tenir compte des interconnexions inter-puces, etc.
Un pico- quoi que ce soit est 10 -12 , donc nos 47 pg et 2,5 × 10 -13 g / B ci-dessus sont à peu près d'un ordre de grandeur. Cela signifie qu'en première approximation, pour construire un seul pool ZFS de taille maximale à partir des plus grandes cartes microSD actuellement disponibles, vous devrez peut-être utiliser la valeur d'atomes d'une planète entière de la taille de la Terre, et seulement si vous commencez avec quelque chose de proche du bon mélange de silicium, de carbone, d'or, etc. de telle sorte que vous ne vous retrouvez pas avec tellement de scories que vous faites sauter l'estimation.
Si vous pensez qu'il est injuste que j'utilise le stockage flash ici au lieu de quelque chose de plus dense comme une bande ou un disque, considérez les débits de données impliqués, ainsi que le fait que nous n'avons même pas essayé d'envisager la redondance ou le remplacement de périphériques. Nous devons supposer que ce pool ZFS de la taille de la Terre sera composé de vdevs qui n'ont jamais besoin d'être remplacés, et qu'ils peuvent transférer des données assez rapidement pour que vous puissiez remplir le pool dans un délai raisonnable. Seul le stockage à semi-conducteurs a un sens ici.
L'approximation ci-dessus est assez approximative, et les densités de stockage continuent de grimper, mais gardez les choses en perspective: à l'avenir, pour réussir cette cascade de construction de piscines ZFS de taille maximale, nous aurons encore besoin d'utiliser la croûte totale à ressources de base des petites planètes .
Max. taille du fichier
Nous avons donc maintenant un système de fichiers de la taille d'une planète . Que dire de la taille des fichiers qui y sont stockés?
Donnons à chaque personne sur la planète sa propre tranche de taille égale de cette piscine:
10 38 ÷ 10 10 ≈ 10 28 ÷ 10 19 ≈ 10 9
C'est la taille de la piscine divisée par la population de la Terre² divisée par la taille maximale du fichier, en chiffres ronds.
En d'autres termes, chaque personne peut stocker environ un milliard de fichiers de taille maximale dans sa petite tranche personnelle de notre baie de stockage ZFS de la taille de la Terre.
(Si cela vous dérange que notre baie de stockage soit toujours de la taille d'une planète ici dans cet exemple, rappelez-vous qu'elle devait être si grande pour atteindre la première limite ci-dessus, il est donc juste de continuer à l'utiliser pour cet exemple ici.)
Cette taille de fichier maximale par fichier est de 16 EiB sous ZFS, ce qui est 16 × plus grand que la taille de volume maximale d'ext4 , qui est considérée comme ridiculement grande aujourd'hui en soi.
Imaginez quelqu'un utilisant sa tranche de Planet ZFS (anciennement Earth) pour stocker des sauvegardes d'images disque ext4 de taille maximale. De plus, ce client dément (il y en a toujours un) a décidé de tarles augmenter, 16 par fichier, juste pour atteindre la taille maximale de fichier ZFS. Cela fait, ce client aura encore la possibilité de recommencer environ un milliard de fois.
Si vous vous inquiétez de cette limite, c'est le genre de problème que vous devez imaginer devoir résoudre. Et ceci sans même entrer dans les données requises bande passante nécessaire pour transférer ce fichier au service de sauvegarde en ligne une fois .
Soyons également clairs sur l'improbabilité de cet ordinateur terrestre. Vous devez d'abord comprendre comment le construire sans le laisser s'effondrer sur lui-même sous la force de la gravité et devenir fondu au centre. Ensuite, vous devrez trouver comment le fabriquer en utilisant chaque atome de la Terre sans laisser de laitier.
Maintenant, puisque vous avez transformé la surface de l'ordinateur de la Terre en un paysage d'enfer, toutes les personnes qui tentent d'utiliser cet ordinateur devraient vivre ailleurs, un endroit où vous entendriez fréquemment des gens maudire la vitesse de ... de légers retards qui ajoutent de la latence à chaque transaction entre l'ordinateur terrestre et l'endroit où ils vivent maintenant. Si vous pensez que votre temps de ping Internet de ~ 10 ms est un problème aujourd'hui, imaginez mettre 2,6 secondes-lumière entre votre clavier et l'ordinateur si nous déplaçons la population de la Terre vers la lune afin que nous puissions créer cet ordinateur terrestre.
Les limitations de volume et de taille de fichier de ZFS sont importantes pour la science-fiction.
Max. nombre de fichiers par répertoire
2 48 représente environ 10 14 fichiers par répertoire, ce qui ne posera de problème qu'aux applications qui essaient de traiter ZFS comme un système de fichiers plat .
Imaginez un chercheur Internet qui stocke des fichiers sur chaque adresse IP sur Internet. Disons qu'il y a exactement 2 32 IP suivis après avoir d'abord soustrait les espaces libres dans l'ancien espace IPv4, puis ajouté les hôtes utilisant désormais des adresses IPv6 pour rendre l'arithmétique agréable. À quel problème ce chercheur tente-t-il de s'attaquer qui l'oblige à construire un système de classement pouvant stocker plus de 2 16 - 65536! - fichiers par IP?
Supposons que ce chercheur stocke également des fichiers par port TCP, de sorte qu'avec un seul fichier par combinaison IP: port, nous avons mangé notre multiplicateur 2 16 .
La solution est simple: stockez les fichiers par IP dans un sous-répertoire nommé d'après l'IP et stockez les fichiers par port dans un sous-répertoire du répertoire contenant les fichiers par IP. Notre chercheur peut désormais stocker 10 14 fichiers par IP: combinaison de ports, suffisante pour un système mondial de surveillance Internet à long terme.
La limite de taille de répertoire de ZFS n'est pas ce que j'appellerais "la science-fiction grande", comme nous le savons aujourd'hui, de vraies applications qui peuvent atteindre cette limite, mais la puissance de la hiérarchie signifie que vous pouvez simplement ajouter une autre couche de répertoire si vous rencontrez le limite.
Cette limite est probablement définie aussi bas que cela uniquement pour éviter de rendre les structures de données nécessaires pour trouver des fichiers dans un répertoire donné trop volumineux pour tenir dans la RAM. Il vous encourage à organiser vos données de manière hiérarchique pour éviter ce problème en premier lieu.
Max. longueur du nom de fichier
Bien que cette seule limite semble stricte, elle est en fait logique.
Cette limite ne provient pas de ZFS. Je crois que cela remonte à FFS dans 4.2BSD . Je ne trouve pas la citation, mais quand cette limite était jeune, quelqu'un a souligné que c'était assez d'espace pour "une courte lettre à grand-mère".
Donc, cela soulève la question: pourquoi avez-vous besoin de nommer vos fichiers de manière plus descriptive que cela? Tout besoin réel supérieur à celui-ci nécessite probablement une hiérarchie, auquel cas vous multipliez la limite par le nombre de niveaux dans la hiérarchie, plus un. Autrement dit, si le fichier est enterré à 3 niveaux dans la hiérarchie, la limite du nom du chemin d'accès complet est de 4 × 255 = 1020 caractères.
En fin de compte, cette limite est une limite humaine, pas une limite technologique. Les noms de fichiers sont à l'usage de l'homme, et les humains n'ont vraiment pas besoin de plus de 255 caractères pour décrire utilement le contenu d'un fichier. Une limite supérieure ne serait tout simplement pas utile. La limitation est ancienne (1983) car les humains n'ont pas acquis la capacité de gérer des noms de fichiers plus longs depuis lors.
Si vous demandez d'où vient la valeur étrange "255", c'est une limitation basée sur la taille d'un octet 8 bits. 2 8 est 256, et la valeur N-1 utilisée ici signifie probablement qu'ils utilisent un terminateur nul pour marquer la fin de la chaîne de nom de fichier dans un champ de 256 octets dans les métadonnées par fichier.
Réponse courte
Concrètement, quelles limites?
Notes de bas de page:
J'ai mesuré cela en utilisant une échelle spécifiée avec une précision de 0,01 g.
7,55 milliards , au moment de la rédaction de cet article. Ci-dessus, nous arrondissons ce chiffre à 10 10 , que nous devrions atteindre d'ici le milieu du siècle .
PATH_MAXsur un système POSIX est 256. Il peut être composé de composants d'au plusNAME_MAXchacun des caractères (cette valeur est au moins 14).