lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sun, 19 Mar 2023 23:25:57 -0700
From:   Christoph Hellwig <hch@...radead.org>
To:     Adrian Hunter <adrian.hunter@...el.com>
Cc:     Christoph Hellwig <hch@...radead.org>,
        Ulf Hansson <ulf.hansson@...aro.org>,
        linux-mmc@...r.kernel.org,
        Wenchao Chen <wenchao.chen666@...il.com>,
        Avri Altman <avri.altman@....com>,
        Christian Lohle <cloehle@...erstone.com>,
        linux-block@...r.kernel.org, linux-kernel@...r.kernel.org,
        Bean Huo <beanhuo@...ron.com>
Subject: Re: [PATCH] mmc: core: Allow to avoid REQ_FUA if the eMMC supports
 an internal cache

On Thu, Mar 16, 2023 at 09:12:35PM +0200, Adrian Hunter wrote:
> 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.

Yes.  Not just file systems, but also all kinds of applications.

> The eMMC spec does not guarantee that,
> except for the eMMC "reliable write" operation.

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.

> So the paragraph
> above is informing the potential benefit of reliable write instead
> of cache flush.

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.


> Note, it is not that eMMC cannot avoid torn sectors, it is that
> the specification does not mandate that they do.

If devices tear writes it will break not only various file systems,
but more importantly applications, at least on file systems without
data checksum (aka all except for btrfs, and even that has a nodatacsum
option).

> 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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ