Qual è il filesystem più veloce per le build degli sviluppatori?

Sto mettendo insieme un box Linux che fungerà da server di build a integrazione continua; costruiremo principalmente materiale Java, ma penso che questa domanda si applichi a qualsiasi linguaggio compilato.

Quali filesystem e impostazioni di configurazione dovrei usare? (Ad esempio, so che non avrò bisogno di tempo per questo!) Il server di compilazione impiegherà molto tempo a leggere e scrivere piccoli file e a scansionare le directory per vedere quali file sono stati modificati.

AGGIORNAMENTO: l'integrità dei dati è una priorità bassa in questo caso; è solo una macchina per costruire ... gli artefatti finali verranno compressi e archiviati altrove. Se il filesystem sulla macchina di compilazione viene danneggiato e perde tutti i dati, possiamo semplicemente cancellare e ri-immagine; le build continueranno a funzionare come prima.

Usa ext4fs come filesystem di base con alcune opzioni di speedup come

noatime,data=writeback,nobh,barrier=0,commit=300

Quindi unione monta un ramdisk tmpfs sopra quello in modo che i file scritti durante le build ottengano i vantaggi del ramdisk. Modificare la procedura di compilazione per spostare i binari risultanti dai tmpfs alla fine della compilazione oppure unire nuovamente i tmpfs in ext4fs prima di smontarli.

File system più veloce? tmpfs montato su RAM disponibile, con noatimeset.

Questo è possibile solo se hai una procedura per estrarre tutto il necessario per costruire il tuo albero dei sorgenti (dato che il contenuto di un filesystem tmpfs scomparirà quando riavvierai) e se i sorgenti e gli oggetti si adattano in un angolo ragionevole della tua RAM disponibile ( con abbastanza spazio per eseguire compilatore e linker senza scambiare). Detto questo, non puoi battere lavorando sulla RAM per la velocità ..

Alla risposta di Michael Dillon posso aggiungere che è possibile creare un filesystem ext4 con poche opzioni:

mkfs.ext4 -O dir_index,extent -i 8096 /dev/<disk>


dir_index
    Use hashed b-trees to speed up lookups in large directories.

extent 
    Instead of using the indirect block scheme for storing the location of data blocks in an inode, use extents instead.  This is a  much  more  efficient  encoding  which  speeds  up filesystem access, especially for large files.

-i 8096 ti dà più inode per dimensione, utile perché gli ambienti di costruzione creano molti file.

Per le fonti sarebbe preferibile avere il supporto di compressione al volo, che è Reiser4 o Btrfs . Entrambi non sono ancora "per la produzione", anche se ho sentito parlare di persone che usano entrambe le FS in modo pesante e felice. :-)

La scelta successiva (di solito lo faccio) è Reiser3 , non Ext3 . Ext3 può essere un po ' più veloce al giorno d'oggi, ma Reiser3 non ha limiti di formato-i-nodi, supporta la modifica online dell'opzione "data =". Ha il supporto "di coda" che consente il confezionamento di piccoli file più stretti, ma se sei preoccupato per la velocità, "notail".

Sia XFS che JFS sarebbero un problema per il caso di "molti file di piccole dimensioni", specialmente se avresti bisogno di modificarli.

(Dimenticato di menzionare EXT4: Sì, è ancora più veloce, quindi EXT3. Ma tutte le limitazioni di EXT3 sopra menzionate sono anche di EXT4).

Le operazioni descritte descrivono alcuni suggerimenti chiave su ciò che il file system ideale deve essere in grado di fare:

• Accessi r / w massicciamente casuali durante il processo di compilazione.
• Molti, molti file vengono aggiornati in breve tempo, quindi le operazioni di metadati veloci sono fondamentali.
• Gestione efficiente di molti piccoli file su file system possibilmente molto pesanti.
• Abbastanza maturo da non rischiare la perdita di dati in casi rari e oscuri.

Btrfs ed Ext4 sono tre dei precedenti e il quarto è discutibile. Ext4 è probabilmente abbastanza maturo per quello, ma btrfs non ha ancora finito di cuocere. noatimeaiuta a rendere più efficienti le operazioni sui metadati, ma quando crei un mucchio di nuovi file, hai ancora bisogno di operazioni sui metadati per essere incredibilmente veloce.

Questo è quando l'archiviazione sottostante inizia a diventare un fattore. Le operazioni di metadati XFS tendono a concentrarsi in pochi blocchi, il che può mettere a dura prova le operazioni. I filesystem in stile Ext sono migliori per avvicinare i metadati ai dati che descrive. Tuttavia, se lo spazio di archiviazione è sufficientemente astratto (in esecuzione in un VPS o collegato a una SAN) , non importa in modo significativo .

Ogni filesystem ha piccole accelerazioni che possono essere fatte per ottenere qualche punto percentuale in più. Quanto è performante l'archiviazione sottostante avrà un grande impatto su quanto guadagno vedrai.

In termini di archiviazione, se si dispone di un sovraccarico di operazioni I / O sufficiente nella memoria, le inefficienze del file system iniziano a non avere importanza. Se usi un SSD per la tua partizione di build, la scelta del filesystem è meno importante di quella con cui ti senti più a tuo agio nel lavorare.

Per molti file di piccole dimensioni, consiglierei Reiser su ext3, xfs, jfs ..., anche se ho sentito che ext4 è molto meglio (cioè il contrario di ciò che dice poise) rispetto alle sue precedenti incarnazioni per questo modello di accesso.

Reiser inserisce molti file nella struttura dell'inode, quindi funziona molto bene quando si tratta di file di piccole dimensioni.

Tuttavia, le differenze di comportamento tra i principali filesystem sono relativamente piccole rispetto ai vantaggi che otterrai avendo abbastanza memoria fisica per memorizzare nella cache / buffer in modo efficace.

e le directory di scansione per vedere quali file sono stati modificati.

Questo è un modo scadente per risolvere il problema, anche se è relativamente semplice. Se è così importante, pensa a scrivere un gestore inotify per indicizzare le mod.

OTOH, se stai usando flash SSD (che ti darà tempi di ricerca molto bassi) ti consiglierei di usare un fs che distribuisce la scrittura in modo più efficace per motivi di longevità - ad esempio JFFS2