On Mar 1 17:07, Pankaj Raghav wrote: > dlfeat was changed from 0x9 to 0x1 when PI support was added. > It was removed because we can't rely on unmap and have to physically > clear it to get the checksums right but that doesnt mean that we do not > support the bit. > > The spec says that if wzds is enabled, then the controller supports > deallocate (DEAC) on write zeroes. But DEAC bit in write zeroes command > is only a hint, the controller might choose to physically write zeroes in > those areas. > > As we are sending write zeroes command with BDRV_REQ_MAY_UNMAP to the > underlying block device anyway (if the unmap operation is supported), > change the dlfeat value back to 0x9. > > A new flag FALLOC_FL_WRITE_ZEROES has been introduced in linux for > fallocate which will use the wzds bit in dlfeat to quickly zeroout extents > using unmap operation whenever possible[1]. > > [1] > https://lore.kernel.org/linux-fsdevel/[email protected]/ > > Fixes: 146f720c55 ("hw/block/nvme: end-to-end data protection") > Suggested-by: Klaus Jensen <[email protected]> > Signed-off-by: Pankaj Raghav <[email protected]> > --- > hw/nvme/ns.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/hw/nvme/ns.c b/hw/nvme/ns.c > index 38f86a1726..b0106eaa5c 100644 > --- a/hw/nvme/ns.c > +++ b/hw/nvme/ns.c > @@ -75,7 +75,7 @@ static int nvme_ns_init(NvmeNamespace *ns, Error **errp) > ns->csi = NVME_CSI_NVM; > ns->status = 0x0; > > - ns->id_ns.dlfeat = 0x1; > + ns->id_ns.dlfeat = 0x9; > > /* support DULBE and I/O optimization fields */ > id_ns->nsfeat |= (NVME_ID_NS_NSFEAT_DAE | NVME_ID_NS_NSFEAT_OPTPERF_ALL); > -- > 2.50.1 >
Applied to nvme-next. Thanks Pankaj!
signature.asc
Description: PGP signature
