10

As ZFS states exclusively, ZFS is claimed to be invulnerable ZFS accepts that it might be vulnerable to power failures.

I couldn't find such a statement for BTRFS. Is it (or designed/planned to be) durable between power outages?

  • read again. " If your pool is damaged due to failing hardware or a power outage, see Repairing ZFS Storage Pool-Wide Damage." (..) Attempt to recover the pool by using the zpool clear -F command – Michael D. Jan 29 '17 at 11:09
  • So you say "ZFS does not guarantee data consistency, it only attempts to recover"? – ceremcem Feb 9 '17 at 8:10
  • Yes. There're several caches to deal with, a hard drives built-in cache, OS caches/buffers. At some point there is a sync or a flush which writes caches to disk, or not during an power outage, that data will be lost. ZFS might work perfectly if the hard disk is healthy and there're no power outages (or an UPS is connected to properly shutdown computer on an outage). Whch you can't say about FAT32 or so. – Michael D. Feb 9 '17 at 8:33
  • 2
    Data loss is not a concern as it is a natural consequence when a power loss is occurred, but, data consistency is a concern in my case. A file system might loose data in such extreme conditions, but should not cause inconsistent data in disk. I need continuous snapshots facility, so I'll keep going with BTRFS. NILFS2 is the closest option in my case though. – ceremcem Feb 9 '17 at 11:58
  • 1
    I've asked the question on #btrfs IRC, they said should be ok if your hw isn't "buggy" where not-"buggy" means your hw has correct flush/barrier semantics. I have posted a link to this question on IRC, hopefully somebody would take time to elaborate; but for now this is it. – Hi-Angel Nov 13 '17 at 9:33
4

I've asked the question on #btrfs IRC, they said should be ok if your hw isn't "buggy" where not-"buggy" means your hw has correct flush/barrier semantics.

TL;DR: This means that btrfs is protected against data corruption due to power loss in a similar way as ZFS.

Here is why: The general idea behind ZFS and btrfs is similar. Both use Merkle trees as a data structure. Writes might require multiple blocks on the disk(s) to be updated. The file system is handling this by writing the new data to empty blocks (even if an existing file is being modified, thus it doesn't need to modify blocks that reflect the old state) and building a new updated tree. Once all the heavy lifting is done and data + the updated tree have been written to the disk the head pointer gets updated to the new tree making the change visible.

Here is how things are supposed to behave when writing to a file:

  1. Write data to free blocks on the disk.
  2. Make a copy of the Merkle tree*, update it according to the changes written in (1).
  3. Ask hardware to flush data to disk - hardware writes all pending data.
  4. Update head pointer to new Merkle tree.
  5. Free old blocks that aren't needed anymore.

If power is lost after (4) the transaction is complete. If power is lost during steps (1) to (3) the file system will come up with the old state (data written in step (1) is lost but the file system is consistent). Note that there is no need to check for file system errors which means the file system is available immediately which is a big advantage (checking large file systems can take very long!).

Here is an example how things can go wrong with "buggy" hardware:

  1. Write data to free blocks on the disk.
  2. Make a copy of the Merkle tree*, update it according to the changes written in (1).
  3. Ask hardware to flush data to disk - hardware confirms completion but doesn't flush all the way (e.g. the data might remain in the disk's write-back cache).
  4. Update head pointer to new Merkle tree. This data gets written to disk before other pending data (e.g. because the head of the disk happens to be at the right location).
  5. Data written in steps (1) and (2) gets written to disk.
  6. Free old blocks that aren't needed anymore.

The file system will become inconsistent if power is lost between (4) and (5) or while performing step (5). As a consequence the Merkle tree and/or the data might only be partially written causing the file system to become inconsistent.

In practice you have to be particularly careful when using RAID controllers. They usually disable the write-back caches on the disk and use their own write-back cache instead. There are two common ways for things to go wrong here:

*I'm simplifying things here. It's actually not necessary to copy the whole tree. Only the parts that changed need to be added - the remaining parts can be shared between the old and the new tree.

  • Thank you for this nice explanation. However, citation needed for all claims, including IRC conversation. Then your answer will be accepted. – ceremcem May 22 at 18:43
  • Regarding the IRC logs, I was referring to @Hi-Angel's comment here. Maybe he can provide a reference? I added a few more references to the other parts, though. – Martin May 22 at 21:32
  • BTRFS doesn't use Merkle trees, it uses B-trees (hence 'B-TRee FileSystem'), and your failure examples requires that write barriers aren't properly implemented by the hardware (which is actually a rather unusual case these days). Otherwise, good answer. – Austin Hemmelgarn May 23 at 11:14
  • The trees used by btrfs are actually both B-trees (this property is about the "shape" of the tree and the fact that they are self-balancing) and hash/Merkle trees (leaves contain the hash of some data, nodes contain the hash of their children, thus each change propagates all the way up to the root). Being able to verify these hashes is what allows btrfs and ZFS to detect corrupted data (and read it from another disk if used in "mirroring" mode). – Martin May 23 at 13:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.