Re: [PATCH] hw/block/nvme: add block utilization tracking

[Klaus Jensen]

On Oct 13 14:06, Keith Busch wrote:
> On Tue, Oct 13, 2020 at 09:08:46PM +0200, Klaus Jensen wrote:
> > From: Klaus Jensen <k.jensen@samsung.com>
> > 
> > This adds support for reporting the Deallocated or Unwritten Logical
> > Block error (DULBE). This requires tracking the allocated/deallocated
> > status of all logical blocks.
> > 
> > Introduce a bitmap that does this. The bitmap is always intialized to
> > all ones (aka, all blocks are allocated) on boot up. Blocks can then be
> > specifically deallocated using Write Zeroes. This ensures that we can
> > always guarantee zeroes to be returned from deallocated blocks.
> > 
> > When the device gains support for persistent state, the intention is to
> > remove the "allocated by default" behavior.
> 
> I think this is a rather odd feature for this device to support. The
> implementation is slow can end up allocating quite a bit of memory.

Totally true - but the bitmap was the best way I could find to do this
on a per LBA basis.

> If we were going to support it here, wouldn't it make more sense to
> tie it to the filesystem's ability to support fallocate hole punch for
> the backing namespace, and check if the range is allocated with
> SEEK_HOLE?  Then you don't even need to track persistent state, and
> we're actually getting the genuine capability.
> 

Yes, this would be optimal, definitely. I think we have to rely on what
we can do with the QEMU block layer, so please see my v2 that uses
bdrv_block_status. I did do something like this initially, but was
unsure if we could live with the fact that block drivers such as qcow2
cannot honor a discard unless an entire cluster is discard/zeroed.

But see my commit message, I think we can work with it and still be in
compliance with the spec.

signature.asc
Description: PGP signature