On Fri, Jan 13, 2012 at 05:16:36AM +0400, Jim Klimov wrote: > 2012-01-13 4:26, Richard Elling wrote: >> On Jan 12, 2012, at 4:12 PM, Jim Klimov wrote: >>> Alternatively (opportunistically), a flag might be set >>> in the DDT entry requesting that a new write mathching >>> this stored checksum should get committed to disk - thus >>> "repairing" all files which reference the block (at least, >>> stopping the IO errors). >> >> verify eliminates this failure mode. > > Thinking about it... got more questions: > > In this case: DDT/BP contain multiple references with > correct checksums, but the on-disk block is bad. > Newly written block has the same checksum, and verification > proves that on-disk data is different byte-to-byte. > > 1) How does the write-stack interact with those checksums > that do not match the data? Would any checksum be tested > for this verification read of existing data at all? > > 2) It would make sense for the failed verification to > have the new block committed to disk, and a new DDT > entry with same checksum created. I would normally > expect this to be the new unique block of a new file, > and have no influence on existing data (block chains). > However in the discussed problematic case, this safe > behavior would also mean not contributing to reparation > of those existing block chains which include the > mismatching on-disk block. > > Either I misunderstand some of the above, or I fail to > see how verification would eliminate this failure mode > (namely, as per my suggestion, replace the bad block > with a good one and have all references updated and > block-chains -> files fixed with one shot).
It doesn't update past data. It gets treated as if there were a hash collision, and the new data is really different despite having the same checksum, and so gets written out instead of incrementing the existing DDT pointer. So it addresses your ability to recover the primary filesystem by overwriting with same data, that dedup was previously defeating. -- Dan.
pgp4l8LOTdUOb.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
