Migration from the KQ Implementation

Jason J. W. Williams jasonjwwilliams at gmail.com
Thu May 5 17:01:30 EDT 2011

> 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.

The straw man is assuming an fsck utility would do anything different
than the recovery mechanisms built into the most recent versions of
ZFS, and that the manual intervention would not still be necessary.
All I keep hearing is "an fsck would fix bad metadata"! To the degree
that's possible in an automated fashion that's what uberblock recovery
and scrub do. Please define beyond that what an fsck utility would do
to avoid the manual intervention circumstances you're referring to? As
Schrock notes in that post, there's nothing more a separate fsck could
do...you'd have to do manual intervention:

"Due to a variety of reasons (hierarchical nature of ZFS, variable block
sizes, RAIDZ-Z, compression, etc), it's difficult to even *identify* a
ZFS block, let alone determine its validity and associate it in some
larger construct."

Given ext3 doesn't vary block size from write to write, an ext3 fsck
utility can make assumptions about what a block looks like and
recognize it when it sees it on xK boundaries. ZFS varies the block
size from write to write up to the maximum block size you set. So you
can't just start tearing through the file system in xK chunks assuming
those chunks are blocks and reading the metadata in the block. You
have to have the metadata intact in the tree to even know where the
next block in the tree starts. Which is why it is so important to let
ZFS handle your RAID for redundancy if you can swing it.


More information about the zfs-discuss mailing list