>>>>> "re" == Richard Elling <richard.ell...@gmail.com> writes:
re> As I said before, if the checksum matches, then the data is
re> checked for sequence number = previous + 1, the blk_birth ==
re> 0, and the size is correct. Since this data lives inside the
re> block, it is unlikely that a collision would also result in a
re> valid block.
That's just a description of how the zil works, not an additional
layer of protection for user data in the ZIL beyond the checksum. The
point of all this is to avoid needing to write a synchronous commit
sector to mark the block valid. Instead, the block becomes valid once
it's entirely written. Yes, the checksum has an additional, critical,
use in the ZIL compared to its use in the bulk pool, but checking
these header fields for sanity does nothing to mitigate broken
fletcher2's weakness in detecting corruption of the user data stored
inside the zil records. It's completely orthogonal.
If anything, the additional use of broken fletcher2 in the ZIL is a
reason it's even more important to fix the checksum in the ZIL:
checksum mismatches occur in the ZIL even during normal operation,
even when the storage is not misbehaving, because sometimes blocks are
incompletely written. This is the normal case, not the exception,
because the ZIL is only read after unclean shutdown.
and AIUI you are saying fletcher2 is still the default for bulk pool
data, too? even on newly created pools with the latest code? The fix
was just to add the word ``deprecated'' to some documentation
somewhere, without actually performing the deprecation? I feel like
FreeBSD/NetBSD would probably have left this bug open until it's
fixed. :/ Ubuntu or Gentoo would probably keep closing and reopening
it though while people haggled in the comments section.
pgpiLfE4opE8N.pgp
Description: PGP signature
_______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
