On Mon, Mar 17, 2025 at 09:15:04AM -0600, Keith Busch wrote: > On Mon, Mar 17, 2025 at 10:49:55AM -0400, Kent Overstreet wrote: > > But we do absolutely require checking for transient read errors, and we > > will miss things and corrupt data unnecessarily without FUA reads that > > bypass the controller cache. > > Read FUA doesn't "bypass the controller cache". This is a "flush cache > first, then read the result" operation. That description seems > consistent for nvme, ata, and scsi. Quoting from your previous email, > 2) read the data and metadata, if any, from non-volatile medium. That's pretty specific. > You are only interested in the case where the read doesn't overlap with > any dirty cache, so the "flush" part isn't a factor. Okay fine, but I'm > still curious if you have actually seen a case where read data was > corrupt in cache but correct with FUA? No. It's completely typical and expected to code defensively against errors which we have not observed but know are possible. Is bit corruption possible in the device cache? You betcha, it's hardware. Are we going to have to test for correct implementation of READ|FUA in the future? Given all the devices that don't even get flushes right, again yes. Are we still going to go ahead and do it? Yes, and I'd even say it's a prerequisite for complaining to manufacturers that don't get this right.
