> 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

Attachment: pgpOIkWS4ZEdB.pgp
Description: PGP signature

_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to