BTRFS garantisce la coerenza dei dati in caso di blackout?

Come afferma esclusivamente ZFS ,Si dice che ZFS sia invulnerabile ZFS accetta che potrebbe essere vulnerabile a interruzioni di corrente.

Non sono riuscito a trovare una simile affermazione per BTRFS. È (o progettato / pianificato per essere) durevole tra le interruzioni di corrente?

Ho fatto la domanda su #btrfs IRC, hanno detto should be ok if your hw isn't "buggy"dove non significa "buggy" your hw has correct flush/barrier semantics.

TL; DR: ciò significa che btrfs è protetto dalla corruzione dei dati a causa della perdita di potenza in modo simile a ZFS.

Ecco perché: l'idea generale alla base di ZFS e btrfs è simile. Entrambi usano gli alberi Merkle come struttura dati . Le scritture potrebbero richiedere l'aggiornamento di più blocchi sui dischi. Il file system lo gestisce scrivendo i nuovi dati in blocchi vuoti (anche se un file esistente viene modificato, quindi non è necessario modificare i blocchi che riflettono il vecchio stato) e costruendo un nuovo albero aggiornato. Una volta fatto tutto il sollevamento pesante e dati + l'albero aggiornato sono stati scritti sul disco, il puntatore della testa viene aggiornato al nuovo albero rendendo visibile la modifica.

Ecco come dovrebbero comportarsi le cose quando si scrive su un file:

1. Scrivi i dati su blocchi liberi sul disco.
2. Crea una copia dell'albero Merkle *, aggiornalo in base alle modifiche scritte in (1).
3. Chiedi all'hardware di scaricare i dati sul disco: l'hardware scrive tutti i dati in sospeso.
4. Aggiorna il puntatore head al nuovo albero Merkle.
5. Vecchi blocchi gratuiti che non sono più necessari.

Se si perde energia dopo (4) la transazione è completa. Se l'alimentazione viene persa durante i passaggi da (1) a (3), il file system presenterà il vecchio stato (i dati scritti nel passaggio (1) vengono persi ma il file system è coerente). Si noti che non è necessario verificare la presenza di errori del file system, il che significa che il file system è immediatamente disponibile, il che rappresenta un grande vantaggio (il controllo di file system di grandi dimensioni può richiedere molto tempo!).

Ecco un esempio di come le cose potrebbero andare storte con l'hardware "buggy":

1. Scrivi i dati su blocchi liberi sul disco.
2. Crea una copia dell'albero Merkle *, aggiornalo in base alle modifiche scritte in (1).
3. Chiedi all'hardware di scaricare i dati sul disco: l'hardware conferma il completamento ma non scarica completamente (ad es. I dati potrebbero rimanere nella cache di riscrittura del disco).
4. Aggiorna il puntatore head al nuovo albero Merkle. Questi dati vengono scritti su disco prima di altri dati in sospeso (ad es. Perché la testa del disco si trova nella posizione corretta).
5. I dati scritti nei passaggi (1) e (2) vengono scritti su disco.
6. Vecchi blocchi gratuiti che non sono più necessari.

Il file system diventerà incoerente se si perde l'alimentazione tra (4) e (5) o durante l'esecuzione del passaggio (5). Di conseguenza l'albero di Merkle e / oi dati potrebbero essere scritti solo in parte, rendendo il file system incoerente.

In pratica devi prestare particolare attenzione quando usi i controller RAID . Di solito disabilitano le cache di write-back sul disco e usano invece la propria cache di write-back. Ci sono due modi comuni in cui le cose vanno male qui:

• La cache del controller RAID è RAM. Se non è supportato da una batteria o da una tecnologia simile, potresti perdere una quantità significativa di dati.
• Alcuni dischi non disabilitano le loro cache di riscrittura quando viene richiesto . È più probabile che ciò accada con unità desktop economiche che con unità server progettate per RAID.

* Sto semplificando le cose qui. In realtà non è necessario copiare l'intero albero. È necessario aggiungere solo le parti modificate: le parti rimanenti possono essere condivise tra il vecchio e il nuovo albero .