Migration from the KQ Implementation

Gordan Bobic 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:
>   http://www.mail-archive.com/zfs-discuss@opensolaris.org/msg20093.html
> 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 mailing list