On Tue, Mar 11, 2025 at 03:53:51PM +0100, Niklas Cassel wrote: > Hello Kent, > > On Tue, Mar 11, 2025 at 09:35:16AM -0400, Kent Overstreet wrote: > > REQ_FUA|REQ_READ means "do a read that bypasses the controller cache", > > the same as writes. > > > > This is useful for when the filesystem gets a checksum error, it's > > possible that a bit was flipped in the controller cache, and when we > > retry we want to retry the entire IO, not just from cache. > > Looking at ATA Command Set - 6 (ACS-6), > 7.23 READ FPDMA QUEUED - 60h > > """ > If the Forced Unit Access (FUA) bit is set to one, the device shall retrieve > the data from the non-volatile media regardless of whether the device holds > the requested information in the volatile cache. > > If the device holds a modified copy of the requested data as a result of > having volatile cached writes, the modified data shall be written to the > non-volatile media before being retrieved from the non-volatile media as > part of this operation. > """ > > So IIUC, at least for ATA, if something is corrupted in the volatile > write cache, setting the FUA bit will ensure that the corruption will > get propagated to the non-volatile media. Corrupted in the volatile writeback cache is not the expected case - we don't usually read data we've just written. Generally, the data will be in the device's cache only because we just read it, and we don't want to retry the read from the device cache. It's possible that either the device's cache was faulty, or there was a transient error in reading from flash (SSD ec algorithms are effectively probabilistic these days), so in either case retrying with a FUA read has a much better chance of clearing a transient error and correctly reading the bad data.
