Migration from the KQ Implementation
gordan.bobic at gmail.com
Thu May 5 16:47:45 EDT 2011
On 05/05/2011 04:54 PM, Jason J. W. Williams wrote:
>> 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.
Well, ext file systems have copies of their equivalent of the uberblock.
If they are all toast, you have a problem, but that comes under the
heading of strange and unusual hardware failure that I mentioned earlier
which isn't what we are discussing here.
> The aforementioned zpool recovery feature attempts to find an earlier
> 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.
Straw man. A number of us here have seen examples of Solaris with it's
native, benchmark implementation failing to mount a file system due to
metadata corruption that WAS recoverable with some manual intervention.
While it may have been an implementation bug, a fsck tool would still
have been useful.
More information about the zfs-discuss