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 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 http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com
pgpXffQuNhb6M.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
