Re: [PATCH 2/2] hw/block/nvme: add write uncorrectable command

[Klaus Jensen <its@irrelevant.dk>]

[-- Attachment #1: Type: text/plain, Size: 2438 bytes --]

On Feb 11 12:37, Keith Busch wrote:
> On Wed, Feb 10, 2021 at 08:06:46AM +0100, Klaus Jensen wrote:
> > From: Gollu Appalanaidu <anaidu.gollu@samsung.com>
> > 
> > Add support for marking blocks invalid with the Write Uncorrectable
> > command. Block status is tracked in a (non-persistent) bitmap that is
> > checked on all reads and written to on all writes. This is potentially
> > expensive, so keep Write Uncorrectable disabled by default.
> 
> I really think attempting to emulate all these things is putting a
> potentially unnecessary maintenance burden on this device.
> 

Even though I myself posted the Telemetry support on behalf of Gollu, I
now agree that it would bloat the device with a "useless" feature. We
totally accept that and in that initial form there was not a lot of bang
for bucks.

This emulated feature comes at a pretty low cost in terms of code and
complexity, but I won't argue beyond that. However, it does comes at a
performance cost, which is why the intention was to disable it by
default.

> The DULBE implementation started off similiar, but I suggested it
> leverage support out of the backing file, and I feel it ended up better
> for it.
> 

And thanks for pushing back against that - the solution we ended up with
was totally superior, no doubt about that!

> But unlike punching and checking for holes, there's no filesystem
> support for Write Uncorrectable in our qemu API, and that's probably
> because this is kind of a niche feature.

True. I don't see any trivial way to support this on a lower level. Even
if we persued implementing this in the QEMU block layer I only think it
could be supported by "integrated formats" like QCOW2 that could
optionally include a persistent bitmap, like the dirty bitmap feature.

> Is there a use case with a real qemu guest wanting this?

Like for the extended metadata case (which also does not have a lot of
"public" exposure, but definitely have enterprise use), our main
motivation here was to ease testing for compliance suites and frameworks
like SPDK. I'm honestly have no clue what so ever what a real world use
of Write Uncorrectable would be. It's been in the spec since 1.0, so
there must have been some reason, Is it just to align with SCSI WRITE
LONG? I'm not SCSI expert at all, but from what I can read it looks like
that was also intended as a feature for testing read error conditions.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]