Filesystem numero elevato di file in una singola directory

OK, non così grande, ma devo usare qualcosa in cui sono memorizzati circa 60.000 file con dimensioni medie di 30kb in una singola directory (questo è un requisito, quindi non posso semplicemente dividere in sottodirectory con un numero inferiore di file).

I file saranno accessibili in modo casuale, ma una volta creati non ci saranno scritture sullo stesso filesystem. Attualmente sto usando Ext3 ma lo trovo molto lento. Eventuali suggerimenti?

Dovresti considerare XFS. Supporta un numero molto elevato di file sia a livello di file system che a livello di directory e le prestazioni rimangono relativamente coerenti anche con un numero elevato di voci a causa della struttura dei dati della struttura B +.

C'è una pagina sulla loro wiki per un gran numero di articoli e pubblicazioni che descrivono in dettaglio il design. Ti consiglio di provarlo e confrontarlo con la tua soluzione attuale.

Un miliardo di file su Linux

L'autore di questo articolo analizza alcuni dei problemi di prestazioni sui file system con un numero elevato di file e fa dei bei confronti delle prestazioni dei vari file system ext3, ext4 e XFS. Questo è reso disponibile come presentazione. http://events.linuxfoundation.org/slides/2010/linuxcon2010_wheeler.pdf

Molti file in una directory su ext3 sono stati discussi a lungo nel sito sorella stackoverflow.com

A mio avviso, 60.000 file in una directory su ext3 sono tutt'altro che ideali, ma a seconda degli altri requisiti potrebbe essere abbastanza buono.

OK. Ho fatto alcuni test preliminari usando ReiserFS, XFS, JFS, Ext3 (dir_hash abilitato) ed Ext4dev (kernel 2.6.26). La mia prima impressione è stata che tutti fossero abbastanza veloci (sulla mia robusta workstation) - si scopre che la macchina di produzione remota ha un processore abbastanza lento.

Ho sperimentato alcune stranezze con ReiserFS anche durante i test iniziali, quindi l'ho escluso. Sembra che JFS abbia il 33% in meno di CPU rispetto a tutti gli altri e quindi lo testerà sul server remoto. Se funziona abbastanza bene, lo userò.

Sto scrivendo un'applicazione che memorizza anche molti file anche se i miei sono più grandi e ne ho 10 milioni che li suddividerò in più directory.

ext3 è lento principalmente a causa dell'implementazione predefinita "elenco collegato". Quindi, se hai molti file in una directory, significa che aprirne o crearne un'altra diventerà sempre più lento. C'è qualcosa chiamato un indice htree disponibile per ext3 che secondo come riferito migliora notevolmente le cose. Ma è disponibile solo per la creazione di filesystem. Vedi qui: http://lonesysadmin.net/2007/08/17/use-dir_index-for-your-new-ext3-filesystems/

Dato che dovrai ricostruire il filesystem comunque e per via delle limitazioni di ext3, la mia raccomandazione è di guardare ext4 (o XFS). Penso che ext4 sia un po 'più veloce con file più piccoli e abbia ricostruzioni più veloci. L'indice Htree è predefinito su ext4 per quanto ne so. Non ho alcuna esperienza con JFS o Reiser, ma ho sentito che la gente lo consiglia prima.

In realtà, probabilmente testerei diversi filesystem. Perché non provare ext4, xfs & jfs e vedere quale offre le migliori prestazioni complessive?

Qualcosa che uno sviluppatore mi ha detto che può accelerare le cose nel codice dell'applicazione non è fare una chiamata "stat + open" ma piuttosto "open + fstat". Il primo è significativamente più lento del secondo. Non sono sicuro di avere alcun controllo o influenza su questo.

Vedi il mio post qui su StackOverflow. Memorizzare e accedere a un massimo di 10 milioni di file in Linux ci sono alcune risposte e collegamenti molto utili.

L'uso di tune2fs per abilitare dir_index potrebbe essere d'aiuto. Per vedere se è abilitato:

sudo tune2fs -l /dev/sda1 | grep dir_index

Se non è abilitato:

sudo umount /dev/sda1   
sudo tune2fs -O dir_index /dev/sad1
sudo e2fsck -D /dev/sda1
sudo mount /dev/sda1

Ma ho la sensazione che potresti seguire una strada sbagliata ... perché non generare un indice piatto e usare del codice per selezionare in modo casuale basato su quello. È quindi possibile utilizzare le sottodirectory per una struttura ad albero più ottimizzata.

ext3 e precedenti supportano fino a 32768 file per directory. ext4 supporta fino a 65536 nel conteggio effettivo dei file, ma ti permetterà di averne di più (semplicemente non li memorizzerà nella directory, il che non ha importanza per la maggior parte degli utenti).

Inoltre, il modo in cui le directory sono archiviate su filesystem ext * è essenzialmente come un grande elenco. Sui filesystem più moderni (Reiser, XFS, JFS) sono archiviati come alberi B, che sono molto più efficienti per grandi set.

È possibile memorizzare gli inode dei file anziché i nomi dei file: l'accesso ai numeri degli inode dovrebbe essere molto più veloce della risoluzione dei nomi dei file

Non vuoi stipare quel numero di file in una directory, vuoi una sorta di struttura. Anche se è qualcosa di semplice come avere sottodirectory che iniziano con il primo carattere del file può migliorare i tempi di accesso. Un altro trucco sciocco che mi piace usare è quello di forzare il sistema ad aggiornare la sua cache con metainformation è quello di eseguire updateb regolarmente. In una finestra esegui slabtop, e in un'altra esegui updateb e vedrai che molta memoria verrà allocata nella cache. È molto più veloce in questo modo.

Non hai specificato il tipo di dati in questi file. Ma dai suoni di ciò, dovresti usare una sorta di database con indicizzazione per ricerche rapide.

Il filesystem non è probabilmente la memoria ideale per tale requisito. Qualche tipo di archiviazione del database è migliore. Tuttavia, se non puoi farne a meno, prova a dividere i file in diverse directory e usa unionfs per montare (associare) quelle directory su una singola directory in cui vuoi che appaiano tutti i file. Non ho usato questa tecnica per accelerare, ma vale la pena provare.