filesystem per l'archiviazione

Ho alcuni dati complessi di sola lettura nel mio file system. Contiene migliaia di istantanee di alcune revisioni di un repository svn e l'output dei test di regressione. I file identici tra le istantanee sono già duplicati utilizzando i collegamenti reali. In questo modo, la capacità di archiviazione non deve essere grande, ma consuma ancora molti inode e questo rende fsck dolorosamente lungo per il mio file system principale.

Vorrei spostare questi dati in un altro file system, in modo che non influisca troppo sul file system principale. Hai suggerimenti? Squashfs sembra essere una scelta possibile, ma dovrò verificare se è in grado di gestire i collegamenti reali in modo efficiente.

Se si tratta di lentezza fsck, hai provato ext4? Hanno aggiunto alcune funzionalità che rendono fsck davvero veloce non guardando gli inode inutilizzati :

Fsck è un'operazione molto lenta, in particolare il primo passo: controllare tutti gli inode nel file system. In Ext4, alla fine della tabella degli inode di ciascun gruppo verrà memorizzato un elenco di inode non utilizzati (con un checksum, per motivi di sicurezza), quindi fsck non controllerà tali inode. Il risultato è che il tempo totale di fsck migliora da 2 a 20 volte, a seconda del numero di inode utilizzati (http://kerneltrap.org/Linux/Improving_fsck_Speeds_in_Ext4). Va notato che è fsck, e non Ext4, che costruirà l'elenco di inode inutilizzati. Ciò significa che è necessario eseguire fsck per ottenere l'elenco degli inode inutilizzati, e solo la successiva esecuzione fsck sarà più veloce (è necessario passare un fsck per convertire comunque un filesystem Ext3 in Ext4). C'è anche una funzione che prende parte a questa accelerazione di fsck: "gruppi di blocchi flessibili"

Btrfs ha il supporto nativo per le istantanee, quindi non dovresti usare hard link per la deduplicazione. Potresti ricreare la tua configurazione corrente creando un filesystem btrfs e caricandolo con la prima revisione di cui hai bisogno, scattando uno snapshot, e quindi facendo avanzare il repository in avanti in ogni punto nel tempo di cui hai bisogno di uno snapshot e scattando uno snapshot per ogni passo. Questo dovrebbe essere più efficiente dei collegamenti reali e anche più semplice da configurare.

Penso anche (anche se sono tutt'altro che sicuro) che squashfs deduplica i file in modo trasparente, quindi anche se non gestisce i collegamenti reali, vedresti comunque dei vantaggi. Se non hai mai bisogno di cambiare i dati nel filesystem, allora probabilmente squashfs è la strada da percorrere, dato che fsck potrebbe essere sostituito da md5sum;)

Preferirei XFS poiché ho ottime esperienze con questo file system. Ma ti consiglio davvero di fare un test con i tuoi dati e tutti i filesystem suggeriti.

Conosco diversi negozi che usano un DataDomain esattamente per quello scopo.

Il tuo script di archiviazione può essere molto semplice (tar o rsync e cron, per esempio), e non devi preoccuparti di gestire hard link o directory che non possono essere hardlink sulla maggior parte dei filesystem. Non sono necessarie copie incrementali se non per conservare la larghezza di banda. Tutta la magia avviene sotto lo strato di blocco. Non è insolito ospitare dati virtuali di 15-20 TB mentre si utilizza solo uno spazio di disco reale di 1-2 TB. Ne rimarranno ancora molti per i backup del disco.

I dati verrebbero forniti su NFS o iSCSI, ma non sono sicuro che si tratti di un problema

Quando FreeBSD ottiene ZFS v23, la deduplicazione sarà disponibile per il resto di noi.