2011-02-16 10 views
24

Sto scrivendo un'app che deve memorizzare molti file fino a circa 10 milioni.Archiviazione e accesso a 10 milioni di file in Linux

Sono attualmente denominati con un UUID e saranno circa 4 MB ciascuno ma sempre della stessa dimensione. Leggere e scrivere da/a questi file sarà sempre sequenziale.

domande

2 principali sto cercando risposte per:

1) Quali filesystem sarebbe meglio per questo. XFS o ext4? 2) Sarebbe necessario memorizzare i file sotto le sottodirectory per ridurre il numero di file all'interno di una singola directory?

Per la domanda 2, noto che le persone hanno tentato di scoprire il limite XFS per il numero di file che è possibile archiviare in una singola directory e non hanno trovato il limite superiore a milioni. Non hanno notato problemi di prestazioni. Che ne dici di ext4?

Cerca su Google googling con persone che fanno cose simili, alcune persone hanno suggerito di memorizzare il numero di inode come un collegamento al file invece del nome del file per le prestazioni (questo è in un indice di database, che sto usando anche). Tuttavia, non vedo un'API utilizzabile per aprire il file in base al numero di inode. Sembra che sia più un suggerimento per migliorare le prestazioni di ext3 che non intendo usare a proposito.

Quali sono i limiti di ext4 e XFS? Quali sono i vantaggi in termini di prestazioni di uno rispetto all'altro e potresti vedere un motivo per utilizzare ext4 su XFS nel mio caso?

+1

Vedere ad es. http://lwn.net/Articles/400629/ – nos

risposta

17

È necessario memorizzare i file in sottodirectory.

EXT4 e XFS entrambi utilizzano metodi di ricerca efficienti per i nomi dei file, ma se fosse necessario eseguire gli strumenti sopra le directory come ls o find vi sarà molto contento di avere i file in blocchi gestibili di 1.000 - 10.000 file.

La cosa numero di inode è migliorare le prestazioni di accesso sequenziale dei file system EXT. I metadati sono memorizzati in inode e se si accede a questi inode fuori uso, gli accessi ai metadati sono randomizzati. Leggendo i tuoi file in ordine di inode si rende anche sequenziale l'accesso ai metadati.

+0

Con la cosa numero di inode, come aprire il file inode? Posso quindi evitare di usare una costosa operazione stat? – Matt

+4

@Matt Non è possibile aprire un file inode (ignorerebbe parte dello schema di controllo degli accessi di Unix).Ma 'readdir' ti dice i numeri di inode, quindi puoi ordinare il tuo elenco di nomi di file per numero di inode e aprirli in quell'ordine. A proposito, "' stat' è costoso "è una semplificazione eccessiva; l'affermazione più accurata è "' stat (f); open (f) 'è un po 'più costoso di" 'h = open (f); fstat (h)' ". (L'operazione costosa che si evita di fare due volte in quest'ultimo caso è * elaborazione del nome *, non dell'accesso al disco.Il differenziale era 2x, ma dovrebbe essere molto meno con i sistemi moderni.) – zwol

+0

@Zack - Grazie per l'utile insite comparativo stat/open vs open/fstat – Matt

8

I moderni filesystem consentono di memorizzare 10 milioni di file nella stessa directory, se lo si desidera. Ma gli strumenti (ls e i suoi amici) non funzioneranno bene.

Si consiglia di inserire un singolo livello di directory, un numero fisso, forse 1.000 directory e inserire i file (10.000 file sono tollerabili alla shell e "ls").

Ho visto sistemi che creano molti livelli di directory, questo è veramente superfluo e aumenta il consumo di inode e rallenta l'attraversamento.

Anche i file 10M non dovrebbero essere un problema, a meno che non sia necessario eseguire operazioni di massa su di essi.

Mi aspetto che sarà necessario sfoltire i vecchi file, ma qualcosa come "tmpwatch" probabilmente funzionerà perfettamente con i file 10M.

+0

Grazie, è mkdir un'operazione lenta? Devo pre-creare le directory all'avvio e da quel momento in poi presumiamo che esistano? – Matt

+0

Buona idea delle directory. È sottile hai ragione. – Matt

+0

Una volta entrati in milioni di file nella stessa directory, ' ext4' inizia a lottare e ottiene collisioni di hash indice. – steve

Problemi correlati