Re: Metadata CRC error detected at xfs_dir3_block_read_verify+0x9e/0xc0 [xfs], xfs_dir3_block block 0x86f58

["Theodore Ts'o" <tytso@mit.edu>]

On Thu, Mar 17, 2022 at 07:49:02AM +0100, Manfred Spraul wrote:
> 
> > > BTRFS and ZFS can also detect torn writes, and if you use the
> > > (non-default) ext4 option "metadata_csum" it will also detect torn
> > Correction - metadata_csum is ienabled by default, I just ran the
> > wrong mkfs command when I tested it a few moments ago.
> 
> For ext4, I have seen so far only corrupted commit blocks that cause mount
> failures.
> 
> https://lore.kernel.org/all/8fe067d0-6d57-9dd7-2c10-5a2c34037ee1@colorfullife.com/

Ext4 uses FUA writes (if available) to write out the commit block.  If
a FUA write can result in torn writes, in my opinion that's a bug with
the storage device, or if eMMC devices don't respect FUA writes
correctly, then we should just disable FUA writes entirely.

In the absence of FUA, ext4 does assume that we can write out the
commit block as a 4k write, and then issue a cache flush.  If your
simulator assumes that the 4k write can be torn, on the assumption
that there is a narrow race between the issuance of the 4k write, the
device writing 1-3 512 byte sectors, and then due to a power failure,
the cache flush doesn't complete and the result is a torn write ---
quite frankly, I'm not sure how any system using checksums can deal
with that situation.  I think we can only assume that that case is in
reality quite rare, even if it's technically allowed by the spec.

	      	    	    	 - Ted