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

[Keith Busch]

On Fri, Oct 16, 2026 at 04:12:08PM +0200, Erwan Velu wrote:
>   job                   | cache   |   IOPS | fsync avg | flushes |  gain
>   ----------------------+---------+--------+-----------+---------+------
>   psync buffered, QD1   | back    |   3885 |   247.6us |  116552 |
>                         | through |  48325 |    15.7us |       0 | x12.4
>   ----------------------+---------+--------+-----------+---------+------
>   io_uring direct, QD1  | back    |   3886 |   238.2us |  116593 |
>                         | through |  41924 |     5.7us |       0 | x10.8
>   ----------------------+---------+--------+-----------+---------+------
>   io_uring direct, QD32 | back    |   5088 |  6173.5us |  117793 |
>                         | through | 140196 |   107.0us |       0 | x27.6
> 
> From NVMe 1.4c (sections 5.21.1.6 and 6.8) up to the NVMe Base
> Specification 2.4 (sections 5.2.30.1.4 and 7.2), a Flush command has no
> effect if the volatile write cache is not enabled.

Yeah, the NVMe Flush operation should be a no-op in the device, so the
dramatic performance difference is a bit alarming. Surely the block
stack's flush machinery is not the reason for the difference, right?

If the device's flush handling is this bad when VWC is disabled, what
happens when you have it enabled? Can you re-run the same test with that
setting?

I'm not necessarily against what you're proposing here, but your numbers
are unexpected.