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.jen...@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