> Without understanding the underlying pathology it's impossible to "fix" a ZFS > pool.
Sorry, but I have to disagree with this. The goal of fsck is not to bring a file system into the state it "should" be in had no errors occurred. The goal, rather, is to bring a file system to a self-consistent state. Ideally, data should be recoverable when it's believed to be good (ZFS has a big advantage here, since the checksums can be used to validate block pointers). The ZFS on-disk data structure is basically a tree. zfsck could fairly easily walk the tree and ensure that, for instance, pools are at the top level; space maps match allocated blocks; block pointers from multiple files don't overlap; file lengths match their allocation; ACLs are not corrupted; compressed data is not damaged; directories are in the proper format; etc. This might be impractical for a large file system, of course. It might be easier to have a 'zscavenge' that would recover data, where possible, from a corrupted file system. But there should be at least one of these. Losing a whole pool due to the corruption of a couple of blocks of metadata is a Bad Thing. This message posted from opensolaris.org _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
