ext3 fsck time vs. dimensione della partizione

Sto facendo il setup per una farm di archiviazione su larga scala, e per evitare la necessità di fscks lunghi un mese, il mio piano è quello di dividere lo storage in numerosi filesystem più piccoli (va bene, dato che ho un albero dei file ben articolato , in modo da poter facilmente avere filesystem separati montati su 1/, 2/, 3/, 4/, ecc).

La mia difficoltà è nel trovare una qualsiasi enumerazione di una dimensione "ragionevole" per un filesystem, per mantenere i tempi di fsck allo stesso modo "ragionevole". Sebbene sia pienamente consapevole del fatto che il tempo assoluto per una determinata dimensione dipenderà in gran parte dall'hardware, non riesco a trovare alcuna descrizione della forma della curva per i tempi di ext3 fsck con dimensioni del filesystem variabili e quali sono le altre variabili ( un file system pieno di file in una singola directory impiega più tempo di uno con 10 file in ciascuna delle migliaia di directory in un albero; file di grandi dimensioni contro file di piccole dimensioni; file di sistema completo vs file di sistema vuoto; e così via).

Qualcuno ha riferimenti a numeri ben studiati su questo? In caso contrario, qualsiasi aneddoto su questi problemi dovrebbe almeno aiutare a guidare la mia sperimentazione, qualora ciò fosse necessario.

EDIT : Per chiarire: indipendentemente dal filesystem, se qualcosa va storto con i metadati, dovrà essere controllato. Se i re-fsck basati sul tempo o sul mount sono abilitati o necessari non è in discussione, e l'unica ragione per cui sto chiedendo numeri specifici per ext3 è perché è il file system più probabile da scegliere. Se conosci un filesystem che ha un processo fsck particolarmente veloce, sono aperto ai suggerimenti, ma deve essere un'opzione solida (afferma che "il filesystem X non ha mai bisogno di fsck!" Sarà deriso e deriso a lungo) . Sono anche consapevole della necessità di backup e il desiderio di fsck non è un sostituto per i backup, tuttavia è sufficiente scartare il filesystem e ripristinarlo dal backup quando si verificano problemi, piuttosto che fsck, sembra davvero,

Secondo un articolo di Mathur et al. (p. 29), il tempo di e2fsck cresce linearmente con la quantità di inode su un filesystem dopo un certo punto. Se il grafico è qualcosa da seguire, sei più efficace con i filesystem fino a 10 milioni di inode.

Passare a ext4 sarebbe d'aiuto - a condizione che il tuo filesystem non sia caricato fino all'orlo, in cui il guadagno in termini di prestazioni (dovuto al non controllo degli inode contrassegnati come inutilizzati) non ha alcun effetto riconoscibile.

Penso che dovrai fare il tuo benchmarking. Una rapida ricerca su Google non ha rivelato nulla, tranne ext4 che è molto più veloce di ext3.

Quindi, crea alcune partizioni ext3, 100 GB, 200 GB, ecc fino alle dimensioni del disco che utilizzerai. Quindi riempili con i dati. Se puoi usare dati che ricordano i tuoi dati di produzione, (file per directory, distribuzione delle dimensioni dei file, ecc.), Sarebbe meglio. Nota che semplicemente copiare i file da un'altra partizione del dispositivo di backup li posizionerà sul disco perfettamente disposti e deframmentati e quindi i tuoi test mancheranno molti dei tempi di ricerca della testa del disco che arriveranno da molte operazioni di scrittura / modifica / eliminazione.

Dovrai anche riflettere su fsck paralleli. Vedi l'ultimo paio di campi in / etc / fstab. Le partizioni sullo stesso disco fisico devono essere eseguite in sequenza; più dischi sullo stesso controller possono essere eseguiti in parallelo, ma fare attenzione a non sovraccaricare il controller e rallentarli.

http://lmgtfy.com/?q=fsck+benchmark

sembra che fsck sui filesystem ext4 sia significativamente più veloce che su ext3, con alcuni rapporti di ext4 fsck essere 10 o anche più volte più veloci di ext3.

due articoli piuttosto interessanti di quella ricerca sono:

http://thunk.org/tytso/blog/2008/08/08/fast-ext4-fsck-times/ ehttp://thunk.org/tytso/blog/2009/02/26/fast-ext4-fsck-times-revisited/

c'è qualche motivo per cui non è possibile utilizzare un filesystem che non ti impone fscks basati sul tempo o sul mount quando riavvii?

(I fsck basati sul tempo mi danno davvero fastidio: per un server di lunga durata praticamente garantisce che dovrai fare un fsck completo ogni volta che aggiorni il kernel).

comunque, XFS è uno dei filesystem di journaling che non forza un fsck. vale la pena dare un'occhiata.