lkml.org 
[lkml]   [2023]   [Mar]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH] mmc: core: Allow to avoid REQ_FUA if the eMMC supports an internal cache
    From
    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.

    \
     
     \ /
      Last update: 2023-03-27 01:04    [W:2.949 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site