> on a UFS ore reiserfs such errors could be corrected. In general, UFS has zero capability to actually fix real corruption in any reliable way.
What you normally do with fsck is repairing *expected* inconsistencies that the file system was *designed* to produce in the event of e.g. a sudden reboot or a crash. This is entirely different from repairing arbitrary corruption. If ZFS says that a file has a checksum error, that can very well be because there is a bug in ZFS. But it can also be the case that there *is* actual on-disk (or in-transit) corruption that ZFS has detected, and given I/O errors back to an application instead of producing bad data. Now it is probably entirely true that onces you *do* have broken hardware or there is some other reason for corruption beyond that which you can design for, ZFS is probably less mature than traditional file systems in terms of the availability of tools and procedures to salvage whatever might actually be salvagable. That is a valid critisicm. But you *have* to realize the distinction between "repairing" fully expected inconsistencies specifically expected as part of regular operation in the event of a crash/power outtage, from problems arrising from misbehaving hardware or bugs in software. ZFS cannot magically overcome such problems, nor can UFS/reiserfs/xfs/whatever else. -- / Peter Schuller PGP userID: 0xE9758B7D or 'Peter Schuller <peter.schul...@infidyne.com>' Key retrieval: Send an E-Mail to getpgp...@scode.org E-Mail: peter.schul...@infidyne.com Web: http://www.scode.org
pgpOIkWS4ZEdB.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss