Re: Incorrect NVMe DLFEAT?

[Klaus Jensen]

On Apr 29 16:51, Harris, James R wrote:
> Hi,

Hi Jim,

> I’m seeing SPDK test failures with QEMU NVMe controllers that I’ve 
> bisected to QEMU commit 2605257a26 (“hw/block/nvme: add the dataset 
> management command”).
>
> The failing tests are related to write zeroes handling.  If an NVMe 
> controller supports DSM, and DLFEAT indicates that deallocated blocks 
> will read back as zeroes, then SPDK uses DEALLOCATE to implement the 
> write zeroes operation.  (Note: SPDK prefers this method to using NVMe 
> WRITE_ZEROES, since the latter is limited to a 16-bit block count.)

The Dataset Management command is advisory, the controller gives no 
guarantee that it will actually deallocate anything. You cannot use DSM 
as a realiable alternative to Write Zeroes. The QEMU emulated nvme 
device exploits this and in many cases wont deallocate anything if it 
does not fit nicely with the underlying block device setup.

> QEMU sets DLFEAT = 0x9 – and actually set it to 0x9 even before this 
> commit.  Since the lower 3 bits are 0b001, it is reporting that 
> deallocated blocks will read back later as 0.  This does not actually 
> seem to be the case however – reading previously deallocated blocks do 
> not actually return 0s.

Can you share the configuration you use for QEMU? DSM works best with 
4096 byte LBAs (logical_block_size=4096) and the raw format driver.

Also, please test with the Error Recovery feature (and set DULBE) to 
test if the device reports that the block is actually deallocated.

> It seems DLFEAT is being set incorrectly here – should probably be 0x8 
> instead?
>
> Thanks,
>
> Jim

--
k