Re: [PATCH] nvme: honor the volatile write cache enable state

[Keith Busch <kbusch@kernel.org>]

On Thu, Oct 22, 2026 at 03:27:50PM +0200, Erwan Velu wrote:
> Le sam. 17 oct. 2026 à 06:25, Erwan Velu <e.velu@criteo.com> a écrit :
> >
> > [...]
> > > Unfortunately, no: there are contradicting statements here.
> [...]
> > If you think it makes the commit message clearer, I can send a v2 with
> > these numbers, the kernel anitly, and the driver level Flush latency above.
> 
> Hey Keith,
> WDYT of these explanations and additional details?
> Hope that's better and could be considered for inclusion in the next
> releases, maybe as a backport to the stable ones as incorrect
> detection of the volatile's cache status can lead to severe
> performance impact on this type of drive.

I just wanted to see if there was any difference in the controller's
Flush behavior when the volatile cache was enabled vs disabled, and this
looks like it's the same either way. The Flush should have been a no-op
to the device with WCE cleared, so something seems off here.

I'm wondering if the device is actually really respecting WCE set to 0
now. That might be tricky to prove, but it wouldn't be the first time a
device lied  about durability. Not saying that's happening here, but the
behavior you're reporting is suspicious: 15usec writes are not
physically possible with TLC NAND (your model says BiCS TLC) without a
cache, and your controller says your cache is volatile.

Anyway, the principle of what you're proposing looks fine to me from a
spec standpoint. I'll get this queued up if I don't see any other review
feedback or concerns that it's going to corrupt something...