Cosa limita internamente queste cose?
Risposta lunga
I limiti di ZFS si basano su numeri interi di dimensioni fisse perché è il modo più veloce per eseguire l'aritmetica in un computer.
L'alternativa si chiama aritmetica di precisione arbitraria , ma è intrinsecamente lenta . Questo è il motivo per cui l'aritmetica di precisione arbitraria è una libreria aggiuntiva nella maggior parte dei linguaggi di programmazione, non il modo predefinito di fare l'aritmetica. Ci sono eccezioni, ma di solito si tratta di DSL orientati alla matematica come bco Wolfram Language .
Se vuoi un'aritmetica veloce, usi parole di dimensioni fisse, punto.
La velocità raggiunta dall'aritmetica di precisione arbitraria è abbastanza scarsa nella RAM di un computer, ma quando un filesystem non sa quante letture deve fare per caricare tutti i numeri necessari nella RAM, sarebbe molto costoso. Un filesystem basato su numeri interi di dimensioni arbitrarie dovrebbe raggruppare ogni numero da più blocchi, richiedendo un sacco di I / O extra da hit di più dischi rispetto a un filesystem che sa in anticipo quanto siano grandi i suoi blocchi di metadati.
Ora parliamo dell'importazione pratica di ciascuno di questi limiti:
Max. dimensione del volume
2 128 byte è effettivamente già infinito. Possiamo scrivere quel numero invece come circa 10 38 byte, il che significa che per raggiungere quel limite, dovresti avere un singolo pool ZFS di dimensioni terrestri in cui ognuno dei suoi 10 50 atomi viene utilizzato per memorizzare i dati, e ciascuno il byte è memorizzato da un elemento non più grande di 10 12 atomi.
10 12 atomi sembrano molto, ma sono solo circa 47 picogrammi di silicio .
La densità dei dati in grammi è 2,5 × 10 -13 g / byte per l'archiviazione microSD, al momento della stesura di questo documento: la più grande scheda SD disponibile è 1 TB e pesa circa 0,25 g.¹ Una scheda microSD non è fatta di puro silicio, ma non si può ignorare la confezione, perché ne avremo bisogno anche nel nostro computer terrestre; supponiamo che la bassa densità della plastica e la maggiore densità dei perni metallici raggiungano una media di circa la stessa densità del silicio. Abbiamo anche bisogno di un po 'di slop qui per tenere conto delle interconnessioni inter-chip, ecc.
Un pico nulla è 10 -12 , quindi il nostro 47 pg e 2,5 × 10 -13 numeri g / B di cui sopra sono circa un ordine di grandezza a parte. Ciò significa che, per una prima approssimazione, per costruire un singolo pool ZFS di dimensioni massime a partire dalle attuali schede microSD più grandi disponibili, potrebbe essere necessario utilizzare un intero atomo di valore di un pianeta delle dimensioni della Terra, e quindi solo se si inizia con qualcosa vicino al giusto mix di silicio, carbonio, oro, ecc. in modo tale da non finire con così tante scorie da perdere la stima.
Se ritieni che sia ingiusto che io stia usando l'archiviazione flash qui invece di qualcosa di più denso come il nastro o il disco, considera le velocità dei dati in questione, nonché il fatto che non abbiamo nemmeno provato a considerare la ridondanza o la sostituzione del dispositivo. Dobbiamo presumere che questo pool ZFS di dimensioni terrestri sarà composto da vdev che non dovranno mai essere sostituiti e che potranno trasferire i dati abbastanza velocemente da riempire il pool in un tempo ragionevole. Solo l'archiviazione a stato solido ha senso qui.
L'approssimazione di cui sopra è piuttosto approssimativa e le densità di archiviazione continuano a salire, ma mantengono le cose in prospettiva: in futuro, per realizzare questa acrobazia della costruzione di pool ZFS di dimensioni massime, avremo ancora bisogno di usare la crosta totale risorse chiave di piccoli pianeti .
Max. dimensione del file
Quindi ora abbiamo un filesystem delle dimensioni di un pianeta . Cosa possiamo dire della dimensione dei file memorizzati al suo interno?
Diamo a ogni persona sul pianeta la propria fetta di quella piscina di pari dimensioni:
10 38 ÷ 10 10 ≈ 10 28 ÷ 10 19 ≈ 10 9
Questa è la dimensione del pool divisa per la popolazione della Terra² divisa per la dimensione massima del file, in numeri tondi.
In altre parole, ogni persona può archiviare circa un miliardo di file di dimensioni massime nella loro piccola porzione personale del nostro array di archiviazione ZFS di dimensioni terrestri.
(Se ti dà fastidio che il nostro array di archiviazione abbia ancora le dimensioni di un pianeta qui in questo esempio, ricorda che doveva essere così grande per raggiungere il primo limite sopra, quindi è giusto continuare a usarlo per questo esempio Qui.)
La dimensione massima del file per file è di 16 EiB in ZFS, che è 16 volte più grande della dimensione massima del volume di ext4 , che oggi è considerata ridicolmente grande a sé stante.
Immagina qualcuno che utilizza la sua porzione di Planet ZFS (precedentemente nota come Earth) per archiviare backup di immagini ext4 di dimensioni massime del disco. Inoltre, questo cliente demente (ce n'è sempre uno) ha deciso di taraumentarli, 16 per file, solo per raggiungere il limite massimo di dimensioni del file ZFS. Fatto ciò, quel cliente avrà ancora spazio per farlo ancora circa un miliardo di volte in più.
Se ti preoccuperai di questo limite, questo è il tipo di problema che devi immaginare di dover risolvere. E questo senza nemmeno entrare nella larghezza di banda dei dati richiesta per trasferire quel file al servizio di backup online una volta .
Cerchiamo anche di essere chiari su quanto sia improbabile quel computer terrestre. Per prima cosa dovresti capire come costruirlo senza lasciarlo crollare su se stesso sotto la forza di gravità e diventare fuso al centro. Quindi dovresti capire come produrlo usando ogni singolo atomo sulla Terra senza scorie rimanenti.
Ora, dal momento che hai trasformato la superficie del computer terrestre in un inferno, tutte le persone che cercano di utilizzare quel computer dovrebbero vivere altrove, un posto dove sentiresti spesso persone che maledicono la velocità di ritardi di luce che aggiungono latenza a ogni transazione tra il computer terrestre e ovunque essi vivano ora. Se pensi che il tuo tempo di ping di Internet di circa 10 ms sia un problema oggi, immagina di mettere 2,6 secondi luce tra la tastiera e il computer se spostiamo la popolazione della Terra sulla luna in modo da poter realizzare questo computer terrestre.
I limiti di volume e dimensioni dei file di ZFS sono fantascientifici.
Max. numero di file per directory
2 48 corrisponde a circa 10 14 file per directory, il che sarà un problema solo per le applicazioni che tentano di trattare ZFS come un filesystem piatto .
Immagina un ricercatore su Internet che sta archiviando file su ciascun indirizzo IP su Internet. Diciamo che ci sono esattamente 2 32 IP che vengono tracciati dopo aver sottratto prima gli spazi allentati nel vecchio spazio IPv4 e quindi aggiungendo gli host ora usando gli indirizzi IPv6 per rendere l'aritmetica piacevole. Quale problema sta cercando di affrontare questo ricercatore che gli impone di costruire un sistema di archiviazione in grado di memorizzare più di 2 16 - 65536! - file per IP?
Supponiamo che questo ricercatore stia archiviando anche i file per porta TCP, quindi con un solo file per IP: combinazione di porte, abbiamo consumato il nostro moltiplicatore 2 16 .
La correzione è semplice: archivia i file per IP in una sottodirectory che prende il nome dall'IP e archivia i file per porta in una sottodirectory della directory che contiene i file per IP. Ora il nostro ricercatore può memorizzare 10 14 file per IP: combinazione di porte, sufficiente per un sistema globale di monitoraggio Internet a lungo termine.
Il limite delle dimensioni della directory di ZFS non è quello che definirei "fantascienza", come sappiamo oggi delle applicazioni reali che possono raggiungere questo limite, ma il potere della gerarchia significa che puoi semplicemente aggiungere un altro livello di directory se ti imbatti nel limite.
Questo limite è probabilmente impostato su un valore puramente basso per evitare che le strutture di dati necessarie per trovare i file in una determinata directory siano troppo grandi per adattarsi alla RAM. Ti incoraggia a organizzare i tuoi dati gerarchicamente per evitare questo problema in primo luogo.
Max. lunghezza del nome file
Sebbene questo limite sembri rigoroso, in realtà ha senso.
Questo limite non ha origine con ZFS. Credo che risale a FFS in 4.2BSD . Non riesco a trovare la citazione, ma quando questo limite era giovane, qualcuno ha sottolineato che questo è abbastanza spazio per "una breve lettera alla nonna".
Quindi, questo pone la domanda: perché hai bisogno di nominare i tuoi file in modo più descrittivo di quello? Qualsiasi vera necessità maggiore di quella probabilmente richiede gerarchia, a quel punto moltiplichi il limite per il numero di livelli nella gerarchia, più uno. Cioè, se il file è sepolto a 3 livelli in profondità nella gerarchia, il limite sul nome del percorso completo è 4 × 255 = 1020 caratteri.
In definitiva, questo limite è un limite umano, non un limite tecnologico. I nomi dei file sono per uso umano e gli umani in realtà non hanno bisogno di più di 255 caratteri per descrivere utilmente il contenuto di un file. Un limite superiore semplicemente non sarebbe utile. La limitazione è vecchia (1983) perché gli umani non hanno acquisito la capacità di far fronte a nomi di file più lunghi da allora.
Se ti stai chiedendo da dove provenga il valore "255" dall'aspetto strano, si tratta di una limitazione basata sulla dimensione di un byte a 8 bit. 2 8 è 256 e il valore N-1 usato qui probabilmente significa che stanno usando un terminatore null per contrassegnare la fine della stringa del nome file in un campo di 256 byte nei metadati per file.
Risposta breve
In pratica, quali limiti?
Note:
L'ho misurato usando una scala specificata con una precisione di 0,01 g.
7,55 miliardi , al momento della stesura di questo documento. Sopra, lo arrotondiamo a 10 10 , che dovremmo colpire entro la metà del secolo .
PATH_MAXsu un sistema POSIX è 256. Questo può essere costituito da componenti al massimoNAME_MAXciascuno di caratteri (questo valore è almeno 14).