On Tue, 21 Mar 2023 at 13:37, Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > > On Mon, Mar 20, 2023 at 04:24:36PM +0100, Ulf Hansson wrote: > > > Neither to ATA or SCSI, but applications and file systems always very > > > much expected it, so withou it storage devices would be considered > > > fault. Only NVMe actually finally made it part of the standard. > > > > Even if the standard doesn't say, it's perfectly possible that the > > storage device implements it. > > That's exactly what I'm saying above. > > > > But these are completely separate issue. Torn writes are completely > > > unrelated to cache flushes. You can indeed work around torn writes > > > by checksums, but not the lack of cache flushes or vice versa. > > > > It's not a separate issue for eMMC. Please read the complete commit > > message for further clarifications in this regard. > > The commit message claims that checksums replace cache flushes. Which > is dangerously wrong. So please don't refer me to it again - this > dangerously incorrect commit message is wht alerted me to reply to the > patch. That was not the intent, but rather to state that REQ_FUA isn't the only thing a filesystem can rely on, there are other things too. If it's striving towards being more tolerant to sudden power failures, I mean. Anyway, thanks for your advice, I will drop these parts from the commit message to make sure it doesn't cause confusion. > > > > > However, the issue has been raised that reliable write is not > > > > needed to provide sufficient assurance of data integrity, and that > > > > in fact, cache flush can be used instead and perform better. > > > > > > It does not. > > > > Can you please elaborate on this? > > Flushing caches does not replace the invariant of not tearing subsector > writes. And if you need to use reliable writes for (some) devices to > not tear sectors, no amount of cache flushing is going to paper over > the problem. Of course, then I get your point! I think the confusing part here is that the internals of the eMMC treats a "reliable write" as a cache flush too. At least this is the case for earlier eMMC devices, where the write-cache couldn't be explicitly controlled by the host. Kind regards Uffe
