On 3/17/22 15:50, Theodore Ts'o wrote:
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@xxxxxxxxxxxxxxxx/
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.
Just checking the eMMC Spec (JESD 84-B51A)
Table 40, Admitted Data Sector Size, Address Mode and Reliable write
Granularity:
Native sector size 4 kB devices with emulation mode off have a write
granularity of 4 kB.
Otherwise the granularity is 512 bytes.
So, to avoid the risk of torn writes for ext4, emulation mode should be
disabled.
For XFS, the spec provides no solution. (20 kB writes that crosses a 32
kB boundary)
But, obviously:
The real issues identified were much simpler and I have no evidence that
torn writes are a real risk.
--
Manfred
