max file per directory in ext4

Gestisco un'applicazione che contiene un archivio file in cui sono archiviati tutti i file con nomi file uguali alle loro somme md5. Tutti i file sono memorizzati in una directory. Attualmente ce ne sono migliaia, ma presto dovrebbero essere milioni di file sul server. Il server corrente esegue Ubuntu 11.10 su un filesystem ext4.

Qualcuno mi ha detto che non è saggio inserire molti file in una directory, poiché ciò creerà un aumento significativo del tempo di ricerca e dell'affidabilità (aveva una storia sui file max a cui una singola directory potrebbe indicare, risultando in un grande elenco di link). Invece ha suggerito di creare sottodirectory, ad esempio sottostringhe del nome file. Tuttavia, questo renderà alcune cose nella mia applicazione molto più ingombranti.

È ancora vero, o i moderni filesystem (ad esempio ext4) hanno modi più efficienti per affrontarli e scalarli naturalmente? Wikipedia ha alcuni dettagli sui filesystem, ma in realtà non dice nulla sui file massimi per directory o sui tempi di ricerca.

Il ext3filesystem e versioni successive supportano l' indicizzazione della directory B-tree con hash . Questo si adatta molto bene purché le uniche operazioni che fai siano aggiungere, eliminare e accedere per nome. Tuttavia, consiglierei comunque di abbattere le directory. In caso contrario, si crea una trappola pericolosa per gli strumenti ( updatedb, ls, due così via) che eseguono altre operazioni su directory che può far saltare in aria se la directory ha troppe voci.

Il nocciolo del problema è scavare nell'inode della directory per il file desiderato. Alcuni filesystem lo fanno meglio di altri. Alcuni si avvicinano ai miliardi, ma se hai solo ... 20K file che arrivano a quei file sono notevolmente più veloci. Inoltre, i conteggi di file di grandi dimensioni creano problemi per alcuni strumenti e possono rendere il backup / ripristino un problema molto più difficile di conseguenza.

In effetti, ho riscontrato lo stesso identico problema nel nostro sviluppo (md5sum come nome file, ridimensionamento dello stesso). Quello che ho raccomandato ai nostri sviluppatori è di tagliare la corda a pezzi. Sono andati con gruppi di 4, ma sul filesystem eravamo in quel momento anche se molti si sarebbero dimostrati problematici dal punto di vista delle prestazioni, quindi hanno finito per dividersi in un gruppo di 3 per le prime 6 terzine e lasciando il resto come il nome file nella directory del terminale.

Gruppo di 4: 4976/d70b/180c/6142/c617/d0c8/9d0b/bd2b.txt
Gruppo di 3:497/6d7/0b1/80c/614/2c6/17d0c89d0bbd2b.txt

Ciò ha il vantaggio di mantenere ridotte le dimensioni delle directory e poiché MD5sum è piuttosto casuale, creerà alberi di directory bilanciati. È improbabile che quest'ultima directory ottenga più di qualche file. E non è stato così difficile lavorare nel nostro codice. Lavoriamo con progetti multi-milione di file, quindi il ridimensionamento è stato molto importante per noi.

I filesystem moderni gestiscono molto bene directory molto grandi, anche con milioni di file. Ma gli strumenti convenzionali no. Ad esempio, elencare una directory così grande con "ls" richiederebbe un tempo piuttosto lungo poiché normalmente legge l'intera directory e la ordina (anche se è possibile usare ls -f per evitare l'ordinamento). Non inizierebbe a mostrare i file fino a quando non verranno letti tutti. La divisione dei nomi aiuta in alcuni casi, ma non in tutti (ad esempio la replica di rsync potrebbe ancora aver bisogno di raccogliere l'intero albero dei nomi).

Potrei suggerire di utilizzare un database SQL invece? Ciò probabilmente trasformerebbe questa debolezza percepita nella tua applicazione in un punto di forza.