Re: [virtio-dev] [PATCH v5] virtio-blk: add zoned block device specification

[Dmitry Fomichev <Dmitry.Fomichev@wdc.com>]

On Mon, 2022-08-29 at 16:46 +0200, Cornelia Huck wrote:
> On Sun, Aug 28 2022, Dmitry Fomichev <dmitry.fomichev@wdc.com> wrote:
> 
> > Introduce support for Zoned Block Devices to virtio.
> > 
> > Zoned Block Devices (ZBDs) aim to achieve a better capacity, latency
> > and/or cost characteristics compared to commonly available block
> > devices by getting the entire LBA space of the device divided to block
> > regions that are much larger than the LBA size. These regions are
> > called zones and they can only be written sequentially. More details
> > about ZBDs can be found at
> > 
> > https://zonedstorage.io/docs/introduction/zoned-storageÂ;.
> > 
> > In its current form, the virtio protocol for block devices (virtio-blk)
> > is not aware of ZBDs but it allows the driver to successfully scan a
> > host-managed drive provided by the virtio block device. As the result,
> > the host-managed drive is recognized by virtio driver as a regular,
> > non-zoned drive that will operate erroneously under the most common
> > write workloads. Host-aware ZBDs are currently usable, but their
> > performance may not be optimal because the driver can only see them as
> > non-zoned block devices.
> > 
> > To fix this, the virtio-blk protocol needs to be extended to add the
> > capabilities to convey the zone characteristics of ZBDs at the device
> > side to the driver and to provide support for ZBD-specific commands -
> > Report Zones, four zone operations (Open, Close, Finish and Reset) and
> > (optionally) Zone Append. The proposed standard extension aims to
> > define this new functionality.
> > 
> > This patch extends the virtio-blk section of virtio specification with
> > the minimum set of requirements that are necessary to support ZBDs.
> > The resulting device model is a subset of the models defined in ZAC/ZBC
> > and ZNS standards documents. The included functionality mirrors
> > the existing Linux kernel block layer ZBD support and should be
> > sufficient to handle the host-managed and host-aware HDDs that are on
> > the market today as well as ZNS SSDs that are entering the market at
> > the time of submission of this patch.
> > 
> > I would like to thank the following people for their useful feedback
> > and suggestions while working on the initial iterations of this patch.
> > 
> > Damien Le Moal <damien.lemoal@opensource.wdc.com>
> > Matias BjÃrling <Matias.Bjorling@wdc.com>
> > Niklas Cassel <Niklas.Cassel@wdc.com>
> > Hans Holmberg <Hans.Holmberg@wdc.com>
> > 
> > Fixes: https://github.com/oasis-tcs/virtio-spec/issues/143
> > Signed-off-by: Dmitry Fomichev <dmitry.fomichev@wdc.com>
> 
> (...)
> 

<snip>

> Is it ok for the device to offer both F_DISCARD and F_ZONED with Z_HA or
> Z_NONE? In that case, is it ok for the driver to negotiate both
> F_DISCARD and F_ZONED, or does it need to pick at most one of them?

Good point, we need to clarify that for HA/NONE devices the discard feature is
negotiated the same way as for regular block devices no matter what is the
setting of F_ZONED bit. 

> 
> > +
> > +If the VIRTIO_BLK_F_ZONED feature is negotiated, then
> > +\begin{itemize}
> > +\item if the driver that can not support host-managed zoned devices
> > +ÂÂÂ reads VIRTIO_BLK_Z_HM from the \field{model} field of \field{zoned}, the
> > +ÂÂÂ driver MUST NOT set FEATURES_OK flag and instead set the FAILED bit.
> 
> [I'll skip commenting on "negotiated" vs "offered", as we need to clarify
> that comprehensively in the whole document.]
> 
> Could the driver simply reject F_ZONED in that case? The device can
> always fail setting FEATURES_OK if the driver does not accept a feature
> that is needed. Maybe make this a "SHOULD NOT"?

My thinking about F_ZONED feature is that the driver should agree to it if it is
up to date to recognize and implement it. But, even if the code is recent enough,
the driver in some cases may not be able to handle zoned devices. For example,
the Linux kernel virtio-blk driver could implement this spec extension, but the
kernel may be built without CONFIG_BLK_DEV_ZONED configuration option. If this is
the case, the driver must prevent HM devices from being successfully scanned as
regular block devices.

> 
> > +
> > +\item if the driver that can not support support zoned devices reads
> > +ÂÂÂ VIRTIO_BLK_Z_HA from the \field{model} field of \field{zoned}, the
> > driver
> > +ÂÂÂ MAY handle the device as a non-zoned device. In this case, the
> > +ÂÂÂ driver SHOULD ignore all other fields in \field{zoned}.
> 
> I would expect a driver that does not support zoned devices at all to
> always reject F_ZONED (including older drivers). Should we mandate that
> the driver does not accept F_ZONED if it cannot handle it?

The F_ZONED feature may be enabled even the backing device is host-aware or non-
zoned for debugging, troubleshooting, etc. In this case, the driver will present
HA devices to the system as non-zoned if it can't present them as zoned. This
will not work for host-managed drives and we have to keep the MUST NOT for HM.


<snip>

> 
> 
> > +The zone descriptor field \field{z_type} \field{virtio_blk_zone_descriptor}
> > +indicates the type of the zone. The available types are
> > VIRTIO_BLK_ZT_CONV(1),
> > +VIRTIO_BLK_ZT_SWR(2) or VIRTIO_BLK_ZT_SWP(3).
> 
> "The following types are available:" ?

I was trying to be consistent with the way other constant values are defined in
the virtblk section of the document. This way, however, is much less cumbersome,
will gladly make this change :)

DF

> 
> > +
> > +\begin{lstlisting}
> > +#define VIRTIO_BLK_ZT_CONVÂÂÂÂ 1
> > +#define VIRTIO_BLK_ZT_SWRÂÂÂÂÂ 2
> > +#define VIRTIO_BLK_ZT_SWPÂÂÂÂÂ 3
> > +\end{lstlisting}
> > +
> > +Read and write operations into zones with the VIRTIO_BLK_ZT_CONV
> > (Conventional)
> > +type have the same behavior as read and write operations on a regular block
> > +device. Any block in a conventional zone can be read or written at any time
> > and
> > +in any order.