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).

Would you please explain?
//Jim Klimov

zfs-discuss mailing list

Reply via email to