Ray Arachelian wrote: > I think it's high time we get an fsck.zfs tool. While attempting to
I think there might be a misunderstanding here. Please read through the original PSARC materials for ZFS, particularly the 1-pager: http://arc.opensolaris.org/caselog/PSARC/2002/240/onepager.opensolaris The reason that ZFS doesn't have fsck isn't because of an oversight or mistake. It's by design. ZFS is designed such that the on-disk data structures are always self-consistent, if they are readable at all. Of course, no file system can guarantee that the on-disk data are always readable. Hardware device failures do happen, and if you have enough failure, you will in fact lose data. That's what backups are all about. What ZFS does guarantee, though, is that if you can read the data, then the structures read are always self-consistent and correct. It guarantees that by a design that ensures that the pointed-to data are always written and committed before the pointers that reference that data. What does fsck do? It reads through the data structures and verifies that the UFS i-nodes and free lists and directory entries are all self-consistent, and applies "reasonable" heuristics to modify them if they are not consistent. But with ZFS, there are no inconsistent on-disk states, so there's nothing that a "fsck.zfs tool" could possibly do. ZFS's zpool "scrub" facility allows you to check for unreadable blocks and, to the extent that the chosen topology allows it, correct for them. So what does that leave? If you have crummy disks, replace them. If you have poor drivers, upgrade or rewrite them. If you're using a technology with consistently badly-written code or poorly-performing interfaces (USB, sadly, seems to fall in this camp), then use something else. The design of the file system is supposed to protect you against random failures due to bad sectors or entire drives or spindles going down; not against all possible data loss or malicious equipment. And if you have found a bug in ZFS, then it needs to be fixed. fsck in UFS is not there as a means to work around bugs in UFS -- if anything, it can be expected to have more bugs than UFS because it's much more rarely used -- but as a means to cope with transient inconsistent on-disk states that may persist between system boots. The same is true for ZFS; if there's a bug, it needs to be fixed, not papered over with another "tool." -- James Carlson 42.703N 71.076W <[email protected]> _______________________________________________ OpenIndiana-discuss mailing list [email protected] http://openindiana.org/mailman/listinfo/openindiana-discuss
