Maybe btrfs has no fsck, [LWN.net]

Maybe btrfs has no fsck,

Posted Jun 23, 2009 6:18 UTC (Tue) by nix (subscriber, #2304)
In reply to: Maybe btrfs has no fsck, by drag
Parent article: What ever happened to chunkfs?

Journals do not protect the filesystem metadata from corruption. They
protect it from being in an inconsistent state after a crash (i.e. part of
the metadata written, other parts not written).

If a kernel bug, cosmic-ray-induced bitflip, or transient drive bug
corrupts the filesystem you still need a fsck. And in the end, that *will*
happen, even with PCIe and ECCRAM: after all, the *CPU* doesn't checksum
everything inside itself, and ECCRAM can't detect all possible failure
modes.

(Log in to post comments)

Maybe btrfs has no fsck,

Posted Jun 24, 2009 19:19 UTC (Wed) by salimma (subscriber, #34460) [Link]

That's why Btrfs, ZFS and (I think) Dragonfly BSD's HammerFS have checksums for each block.

Maybe btrfs has no fsck,

Posted Jun 26, 2009 11:16 UTC (Fri) by mangoo (guest, #32602) [Link]

How would that help if I, for example, copy one block and its checksum into another area of the disk? Essentially, the block will be valid (checksum matches), but the filesystem will be corrupted.

In a virtual environment, it's not so hard to do such a mistake: just accidentally mount the filesystem twice (i.e. from a guest and a host), and two different kernels will write correct blocks all over, each one corrupting the filesystem.