On 5-Mar-09, at 2:03 PM, Miles Nordin wrote:
"gm" == Gary Mills <mi...@cc.umanitoba.ca> writes:gm> There are many different components that could contribute to gm> such errors. yes of course. gm> Since only the lower ZFS has data redundancy, only it can gm> correct the error. um, no? ... For writing, application-level checksums do NOT work at all, because you would write corrupt data to the disk, and notice only later when you read it back, when there's nothing you can do to fix it.
Right, it would have to be combined with an always read-back policy in the application...?
--Toby
ZFS redundancy will not help you here either, because you write corrupt data redundantly! With a single protection domain for writing, the write would arrive at ZFS along with a never-regenerated checksum wrapper-seal attached to it by the something-like-an-NFS-client. Just before ZFS sends the write to the disk driver, ZFS would crack the protection domain open, validate the checksum, reblock the write, and send it to disk with a new checksum. (so, ``single protection domain'' is really a single domain for reads, and two protection domains for write) If the checksum does not match, ZFS must convince the writing client to resend---in the write direction I think cached bad data will be less of a problem. ...
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
