Re: [PATCH] mmc: core: Allow to avoid REQ_FUA if the eMMC supports an internal cache

[Adrian Hunter <adrian.hunter@intel.com>]

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.