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

Attachment: pgpXffQuNhb6M.pgp
Description: PGP signature

zfs-discuss mailing list

Reply via email to