On 16/03/23 18:49, Christoph Hellwig wrote: > On Thu, Mar 16, 2023 at 05:45:14PM +0100, Ulf Hansson wrote: >> File systems typically uses REQ_FUA for writing their meta-data and other >> important information. Ideally it should provide an increased protection >> against data-corruption, during sudden power-failures. This said, file >> systems have other ways to handle sudden power-failures too, like using >> checksums to detect partly-written data, for example. > > Sorry, but this is completely wrong and dangerous, if not intentionally > misleading bullshit. There is some context missing. Historically file systems have assumed that sectors are updated atomically i.e. there is never a sector with a mixture of old and new data. The eMMC spec does not guarantee that, except for the eMMC "reliable write" operation. So the paragraph above is informing the potential benefit of reliable write instead of cache flush. Note, it is not that eMMC cannot avoid torn sectors, it is that the specification does not mandate that they do. 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. This patch adds a card quirk MMC_QUIRK_AVOID_REL_WRITE that can be set for cards where cache flush outperforms reliable write. We would expect acks from someone in the manufacturer's organization on patches setting the quirk, effectively assuring fitness-for-purpose, and implying that torn sectors are not especially more likely than any other sort of data integrity failure. > > The only way to provide data integrity is to ensure data is written to > the media and not a cache. That can be done by a full blown cache > flush, or with a FUA-like optimization. The patch is just reporting (via blk_queue_write_cache()) that FUA is not supported, so a flush will be done instead.
