Quali dimensioni di blocco per milioni di piccoli file

Ho 2 dischi da 4 TB in RAID1 hardware (potrebbe essere un MegaRaid LSI) su Debian Wheezy. La dimensione del blocco fisico è di 4kB. Ho intenzione di memorizzare 150-200 milioni di file di piccole dimensioni (tra 3 e 10 KB). Non sto chiedendo prestazioni, ma le migliori dimensioni di file system e blocchi per risparmiare spazio di archiviazione. Ho copiato un file di 8200 byte su un ext4 con dimensione del blocco di 4kB. Questo ha richiesto 32kB di disco !? Il journaling è la ragione? Quindi quali opzioni ci sono per salvare la maggior parte dello spazio di archiviazione per file così piccoli?

— rabudde
fonte

Vedi anche: Come posso determinare la dimensione del blocco di una partizione ext3 su Linux?

— Chris S,

Se mi trovassi in quella situazione, guarderei un database in grado di memorizzare tutti i dati in un singolo file con un indice compatto, basato su offset, anziché come file separati. Forse un database che ha un driver FUSE disponibile per interagire con esso come file quando necessario, senza che in realtà siano ESSERE tutti file separati.

In alternativa, si potrebbe osservare il 60 - 70 ° percentile delle dimensioni dei file e provare ad adattare tale dimensione del file direttamente nei nodi dell'albero del filesystem, anziché come blocchi separati sul disco. Memorizzare 10k in ciascun nodo è probabilmente una grande richiesta, ma se si potesse ottenere il 60% -70% di file, sarebbe probabilmente una grande vittoria.

Solo alcuni filesystem possono farlo (reiserfs è uno), e immagino che tutto dipenda dalle dimensioni di quel percentile, se si adatterà all'albero. Potresti essere in grado di sintonizzarlo. Immagino che provi ad adattare il resto in un blocco.

E non preoccuparti delle riviste; hanno comunque un limite di dimensione superiore.

No no no no no no no no solo ... no al tuo primo paragrafo. Ho fatto questo errore anni fa e in seguito ha dovuto essere annullato. Ho anche ereditato sistemi che utilizzano questo modello di progettazione. I file appartengono al file system, o come compromesso, in un oggetto FileStream di SQL Server se è necessario combinarli (quindi forse il driver FUSE, ma ancora semplicemente no). Ci sono altre considerazioni quando si lavora nel filesystem, come non mettere 4 milioni di file in una cartella (ho anche fatto quell'errore).

— Mark Henderson,

@MarkHenderson, ma il problema è definire quale DOVREBBE essere un file e quale dovrebbe essere un record. Senza che siano stati forniti ulteriori dettagli, centinaia di milioni di piccole cose mi sembrano MOLTO più simili ai dischi. Solo perché al momento li ha come file, ciò non significa che debbano rimanere in quel modo, o avrebbero mai dovuto essere in quel modo. Inoltre, non ho mai suggerito per un secondo di usare SQL Server per il lavoro;)

5 anni fa ho ereditato un sistema con 1 milione di file in una singola cartella e circa 10.000 nuovi file da 1-4 KB ogni giorno. Ho deciso di buttarli tutti in un tavolo ISAM perché "Ehi, sono solo testo semplice da analizzare!" e poi quello si è rivelato un errore enorme perché ora avevo un singolo tavolo da 12 GB con un miliardo di file che per lo più non facevano nulla dopo essere stati elaborati. Quindi sono tornato a metterli in un filesystem con cartelle ereditarie basate sul GUID del nome file.

— Mark Henderson,

(perché un singolo tavolo da 12 GB con righe squllion era un problema era una questione diversa che non entrerò qui)

— Mark Henderson

@MarkHenderson: Non è un problema diverso, ecco perché hai detto che era la soluzione sbagliata ("... errore enorme perché ora avevo un solo tavolo da 12 GB con un miliardo di righe ..."). Scegli il formato del motore / tabella del database errato, ma il concetto di mettere molte piccole cose in un singolo file con un INDICE è valido, purché lo faccia nel modo giusto. Quello che vuoi è un database che eccelle negli archivi chiave / valore per milioni di piccoli oggetti, con auto-sharding. Nota anche che non si preoccupa nemmeno delle prestazioni, ma solo dello spazio.