Migration from the KQ Implementation
Jason J. W. Williams
jasonjwwilliams at gmail.com
Thu May 5 11:54:26 EDT 2011
> FWIW, I think ZFS is a very cool toy, and a usable stopgap until BTRFS
> is complete, but not a sane choice for real use because its designers
> care more about being able to point out that something is wrong than
> they do about pragmatic concerns like actually fixing it - or even
> trying to make the best possible attempt.
On Linux perhaps it's a toy. At our shop and many much larger like Joyent ZFS has been a critical and reliable piece of infrastructure.
The mentality on this discussion is that fsck is magic. It's not...it's a recovery tool for repairing metadata. In ZFS everything starts with the uberblock and trees off from there. If your uberblock is toast, you can't mount the FS or begin a repair because neither the FS or a repair tool would know where to start. The aforementioned zpool recovery feature attempts to find an earlier version of the uberblock and rollback to that. Once that is done you can import the pool. From there any repair utility would have to traverse the tree looking for corruption and repairing it by replacing the block. This is what scrub does when you have redundancy.
ZFS isn't missing an fsck because the designers are arrogant and ignoring a tool users need. I know several of what was the core ZFS team personally including Bill Moore and Eric Schrock, and have met Bonwick. Their utmost concern was data reliability and user protection/focus. Here's a better explanation than I could do by Schrock of how ZFS already does what you expect an fsck to do and why a separate utility doesn't make sense:
Blaming ZFS proper for ZFS-fuse failures to import is a non sequiter. That implementation doesn't use the ZFS test suite to test for pathological behavior. Same goes for ZFS on Linux until they're able to use the test suite. If you need to do recovery, an OpenSolaris live CD is going to be your best bet until they pass the ZFS test suite.
More information about the zfs-discuss