Re: [PATCH 00/16] hw/block/nvme: zoned namespace command set

[Klaus Jensen]

On Sep 25 17:06, Dmitry Fomichev wrote:
> > From: Klaus Jensen <k.jensen@samsung.com>
> > 
> >   * Standard blockdev-based approach to persistent state. The
> > 
> >     implementation uses a plain blockdev associated with the nvme-ns
> > 
> >     device for storing state persistently. This same 'pstate' blockdev
> > 
> >     is also used for logical block allocation tracking.
> > 
> 
> Is persistent state mandatory or optional? Sorry for asking, but I am
> still catching up with your other patches. I think having it optional is
> a big benefit for performance testing.
> 

Yes, the 'pstate' blockdev is optional.

> > 
> > 
> >   * Relies on automatic configuration of DLFEAT according to what the
> > 
> >     underlying blockdev provides (i.e. BDRV_O_UNMAP for guaranteeing
> > 
> >     zeroes on discarded blocks) for handling reads in the gaps between
> > 
> >     write pointer, ZCAP and ZSZE. Issues discards for zone resets. This
> > 
> >     removes the zero filling.
> > 
> 
> Doesn't this make non-zero fill patterns impossible? In many storage
> environments, vendors and admins are adamant about having varying
> fill patterns to see who caused the data corruption if there is one.
> Not sure how important this for the particular application, but WDC
> series provides the functionality to specify the fill pattern.
> 

That *is* a good point.

By default I think it should default to either the 0x00 fill pattern (if
supported by the underlying blockdev), or "no fill pattern reported"
when 0x00's cannot be guaranteed. But, an option to enable filling with,
say 0xff, like you do in your series, would be nice.

signature.asc
Description: PGP signature