>I think the problem for me is not that there's a risk of data loss if >a pool becomes corrupt, but that there are no recovery tools >available. With UFS, people expect that if the worst happens, fsck >will be able to recover their data in most cases.
Except, of course, that fsck lies. In "fixes" the meta data and the quality of the rest is unknown. Anyone using UFS knows that UFS file corruption are common; specifically, when using a "UFS root" and the system panic's when trying to install a device driver, there's a good chance that some files in /etc are corrupt. Some were application problems (some code used fsync(fileno(fp)); fclose(fp); it doesn't guarantee anything) >With ZFS you have no such tools, yet Victor has on at least two occasions >shown that it's quite possible to recover pools that were completely unusable >(I believe by making use of old / backup copies of the uberblock). True; and certainly ZFS should be able backtrack. But it's much more likely to happen "automatically" then using a recovery tool. See, fsck could only be written because specific corruption are known and the patterns they have. With ZFS, you can only backup to a certain uberblock and the pattern will be a surprise. Casper _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
