Ragionamento dietro l'hosting delle immagini del disco virtuale sul filesystem BTRFS

Ho letto su BTRFS e ZFS da un po 'e mentre apprezzo i vantaggi di CoW quando si ospitano file importanti, sono attualmente sconcertato dal seguente dilemma:

Dato che sia ZFS che BTRFS sembrano subire un degrado delle prestazioni quando si ospitano file di grandi dimensioni soggetti a scritture casuali (ad esempio QCOW2, VDIs, ecc.), Perché qualcuno dovrebbe usare BTRFS come FS di scelta per ospitare le VM?

So che nel caso di BTRFS puoi disattivare selettivamente CoW usando chattr o l'opzione di montaggio nodatacow, riducendo il degrado imposto dalla frammentazione e CoW ...

Tuttavia, secondo Redhat anche questo "disabilita la verifica del checksum di dati e metadati, con conseguente riduzione dell'integrità dei dati". (oltre alla compressione persa e naturalmente al CoW tanto desiderato).

Sulla base di ciò che chiedo: perché qualcuno dovrebbe scegliere BTRFS su diciamo, XFS su LVM su MD RAID?

Se il caso d'uso principale è l'archiviazione di immagini o database VM e non sei interessato ad accettare i potenziali problemi di prestazioni al fine di ottenere i vantaggi di integrità dei dati di btrfs, non riesco a pensare a nessun motivo per cui vorresti scegliere btrfs su xfs o ext4.

La disabilitazione della copia su scrittura solo per la directory delle immagini della macchina virtuale (usando chattr + C) è principalmente rilevante quando la memorizzazione delle immagini della macchina virtuale è solo uno dei tanti usi che hai per il tuo file system. Quindi può essere molto conveniente disabilitare semplicemente il copy-on-write per quella singola directory, mantenendo comunque tutti i vantaggi di btrfs per il resto del file system.

BTRFS ha un formato del disco diverso che supererà gli altri file system su alcuni schemi di scrittura. In particolare, è stato compiuto un grande sforzo per migliorare la modalità di scrittura dei metadati su disco e supporta alcune funzionalità avanzate come il checksum dei dati, la compressione e le istantanee. Per file di grandi dimensioni il miglioramento delle prestazioni dei metadati non è generalmente importante.

Rispetto a ZFS, BTRFS è una soluzione più semplice e meglio supportata su Linux. Il principale svantaggio è che non viene ridimensionato (quando si aggiunge un numero elevato di dischi) e non ha lo stesso set di funzionalità.

Rispetto a XFS sarà una soluzione a prestazioni inferiori. Vale a dire che ci vorrà più tempo del processore per scrivere un blocco di dati sul disco e sarà limitato nella velocità massima. Questo può essere mitigato in una certa misura facendo cose come disabilitare la verifica del checksum, ma poi perdi il vantaggio principale di BTRFS su XFS che è il miglioramento delle informazioni sui metadati. Vale a dire checksum e journaling diverso (che potrebbe essere migliore in alcune situazioni).

In termini di supporto di Copy On Write (COW), XFS privilegia le prestazioni piuttosto che essere strettamente COW. Vale a dire XFS ha ottime funzionalità di metadati e journaling in termini di scalabilità e generalmente non sovrascrive i dati dei file in scrittura, con l'eccezione del fatto che consentirà di sovrascrivere i blocchi di dischi esistenti se l'applicazione richiede specificamente di sovrascrivere quei dati . Questo può essere utile nel caso di una macchina virtuale poiché l'allocazione del disco inizialmente può essere contigua e in tal caso rimarrebbe contigua per la vita della macchina virtuale.

Usando BTRFS, anche con nodatacowe simili, sei ancora in grado di creare manualmente istantanee di dati con CoWcomportamento, quindi è veloce e non consuma molta memoria. Inoltre, tali snapshot sono più flessibili rispetto all'utilizzo di LVM, poiché non è necessario riservare spazio sotto il file system di cui il file system non è a conoscenza e non può essere utilizzato se non necessario. Come con ZFS, le istantanee possono essere inviate e ricevute attraverso la rete, il che potrebbe aiutarti a migliorare la tua strategia di backup. Quindi anche con nodatacowBTRFS sembra essere superiore rispetto all'uso di LVM.

Dopo aver lavorato con le piattaforme di cloud computing, sono arrivato ad adottare la loro visione delle macchine virtuali come contenitore di dati e funzionalità in cui la vm effettiva è meno importante.

Preferirei avere buoni processi di backup-restore e install-deploy in atto e preoccuparmi meno dell'integrità della VM e di più delle prestazioni.

Vale a dire JFS / XFS / EXT4 su LVM su MD-raid anziché BTRFS. Assicurati di non archiviare mai nulla di cui non è stato eseguito il backup nella VM per un periodo di tempo più lungo ... e di disporre di script e procedure per ottenere il backup di una nuova installazione della VM entro un tempo ragionevole qualora dovesse accadere qualcosa.

Ma questo è più uno scenario di sviluppo / esperimento che altro.