I'd argue that from a *developer* point of view, an fsck tool for ZFS might
well be useful. Isn't that what zdb is for? :-)
But ordinary administrative users should never need something like this, unless
they have encountered a bug in ZFS itself. (And bugs are as likely to exist in
the checker tool as in the filesystem. ;-)
On Oct 19, 2011, at 2:15 PM, Pawel Jakub Dawidek wrote:
> On Wed, Oct 19, 2011 at 08:40:59AM +1100, Peter Jeremy wrote:
>> fsck verifies the logical consistency of a filesystem. For UFS, this
>> includes: used data blocks are allocated to exactly one file,
>> directory entries point to valid inodes, allocated inodes have at
>> least one link, the number of links in an inode exactly matches the
>> number of directory entries pointing to that inode, directories form a
>> single tree without loops, file sizes are consistent with the number
>> of allocated blocks, unallocated data/inodes blocks are in the
>> relevant free bitmaps, redundant superblock data is consistent. It
>> can't verify data.
> 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
> 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 http://www.wheelsystems.com
> FreeBSD committer http://www.FreeBSD.org
> Am I Evil? Yes, I Am! http://yomoli.com
> zfs-discuss mailing list
zfs-discuss mailing list