Hacker News Reader

Comment by tobias3 | Hacker News Reader

No it is worse with ZFS because it doesn't have a fsck tool. If you have a bit flip in the ZFS metadata you have to export and re-import your whole pool to get it to a writable state again.

View on HN

Meanwhile fsck on a traditional filesystem will gleefully mangle data that's actually fine in face of transient corruptions.

I've had this happen more than once, both with bad RAM and bad IO controllers - previously fine static data suddenly being detached from the filesystem and appearing in little bits in lost+found, because bit flips effectively causes it to hallucinate problems to "fix".

This is wrong. But flips can do many different things:

http://open-zfs.org/w/index.php?title=Hardware&mobileaction=...

Export/import is not a solution to most of those. In the cases where it does work, umount/mount is likely all that is needed.

http://open-zfs.org/wiki/Hardware#Background

This would seem to indicate that this sort of thing is exceedingly rare and similar issues would have similar effects on other filesystems.

Resilvering (which is basically a global data verify, similar to fsck) will fix bits flipped the wrong way via error correction, assuming you've set ZFS up that way. Are you saying this doesn't apply to the metadata?

A simple scrub will repair blocks that have checksum failures, but there's is no guarantee that the checksum was calculated before the bit flipped if it occurred in a buffer being written.

What is scrubbing and resilvering if not a fsck equivalent?

Scrubbing corrects on disk bit flips. An in-memory bit flip (which is more rare than on disk bit flips even with non-ECC memory) can corrupt a in-memory data structure which is later written to disk to all replicas, i.e. scrub will not detect it. If this corrupted data structure is later loaded and used this may cause all kinds of problems and there is no tooling to correct it.

Scrub?

Reply on news.ycombinator.com