Thank you. The following is the best "layman's" explanation as to
_why_ ZFS does not have an fsck equivalent (or even needs one). On the
other hand, there are situations where you really do need to force ZFS
to do something that may not be a"good idea", but is the best of a bad
set of choices. Hence the zpool import -F (and other such tools
available via zdb). While the ZFS data may not be corrupt, it is
possible to corrupt the ZFS metadata, uberblock, and labals in such a
way that force is necessary.

On Wed, Oct 19, 2011 at 8:15 AM, Pawel Jakub Dawidek <> wrote:

> Well said. I'd add that people who insist on ZFS having a fsck are
> missing the whole point of ZFS transactional model and copy-on-write
> design.
> Fsck can only fix known file system inconsistencies in file system
> structures. Because there is no atomicity of operations in UFS and other
> file systems it is possible that when you remove a file, your system can
> crash between removing directory entry and freeing inode or blocks.
> This is expected with UFS, that's why there is fsck to verify that no
> such thing happend.
> In ZFS on the other hand there are no inconsistencies like that. If all
> blocks match their checksums and you find directory loop or something
> like that, it is a bug in ZFS, not expected inconsistency. It should be
> fixed in ZFS and not work-arounded with some fsck for ZFS.
> --
> Pawel Jakub Dawidek             
> FreeBSD committer               
> Am I Evil? Yes, I Am!           
> _______________________________________________
> zfs-discuss mailing list

Paul Kraus
-> Senior Systems Architect, Garnet River ( )
-> Sound Coordinator, Schenectady Light Opera Company ( )
-> Technical Advisor, RPI Players
zfs-discuss mailing list

Reply via email to