Re: [Qemu-devel] [Qemu-block] [PATCH v3 0/4] virtio/block: handle zoned backing devices

[Dmitry Fomichev]

John, please see inline...

Regards,
Dmitry

On Thu, 2019-07-25 at 13:58 -0400, John Snow wrote:
> 
> On 7/23/19 6:19 PM, Dmitry Fomichev wrote:
> > Currently, attaching zoned block devices (i.e., storage devices
> > compliant to ZAC/ZBC standards) using several virtio methods doesn't
> > work properly as zoned devices appear as regular block devices at the
> > guest. This may cause unexpected i/o errors and, potentially, some
> > data corruption.
> > 
> 
> Hi, I'm quite uninitiated here, what's a zoned block device? What are
> the ZAC/ZBC standards?
Zoned block devices (ZBDs) are HDDs that use SMR (shingled magnetic
recording). This type of recording, if applied to the entire drive, would
only allow the drive to be written sequentially. To make such devices more
practical, the entire LBA range of the drive is divided into zones. All
writes within a particular zone must be sequential, but writing different
zones can be done concurrently in random manner. This sounds like a lot of
hassle, but in return SMR can achieve up to 20% better areal data density
compared to the most common PMR recording.

The same zoned model is used in up-and-coming NVMe ZNS standard, even
though the reason for using it in ZNS is different compared to SMR HDDs -
easier flash erase block management.

ZBC is an INCITS T10 (SCSI) standard and ZAC is the corresponding T13 (ATA)
standard.

The lack of limelight for these standards is explained by the fact that
these devices are mostly used by cloud infrastructure providers for "cold"
data storage, a purely enterprise application. Currently, both WDC and
Seagate produce SMR drives in significant quantities and Toshiba has
announced support for ZBDs in their future products.

> > 
> I've found this:
> https://www.snia.org/sites/default/files/SDC/2016/presentations/smr/DamienLeMoal_ZBC-ZAC_Linux.pdf
> 
AFAIK, the most useful collection of public resources about zoned block
devices is this website -
http://zonedstorage.io
The site is maintained by our group at WDC (shameless plug here :) ).
BTW, here is the page containing the links to T10/T13 standards
(the access might be restricted for non-members of T10/T13 committees) -
http://zonedstorage.io/introduction/smr/#governing-standards

> It looks like ZAC/ZBC are new commands -- what happens if we just don't
> use them, exactly?
The standards define three models of zoned block devices: drive-managed,
host-aware and host-managed.

Drive-managed zoned devices behave just like regular SCSI/ATA devices and
don't require any additional support. There is no point for manufacturers
to market such devices as zoned. Host-managed and host-aware devices can
read data exactly the same way as common SCSI/ATA drives, but there are
I/O pattern limitations in the write path that the host must adhere to.

Host-aware drives will work without I/O errors under purely random write
workload, but their performance might be significantly degraded
compared to running them under zone-sequential workload. With
host-managed drives, any non-sequential writes within zones will lead
to an I/O error, most likely, "unaligned write".

It is important to mention that almost all zoned devices that are
currently on the market are host-managed.

ZAC/ZBC standards do add some new commands to the common SCSI/ACS command
sets, but, at least for the host-managed model, it wouldn't be sufficient
just to never issue these commands to be able to utilize these devices.

> 
> > To be more precise, attaching a zoned device via virtio-pci-blk,
> > virtio-scsi-pci/scsi-disk or virtio-scsi-pci/scsi-hd demonstrates the
> > above behavior. The virtio-scsi-pci/scsi-block method works with a
> > recent patch. The virtio-scsi-pci/scsi-generic method also appears to
> > handle zoned devices without problems.
> > 
> 
> What exactly fails, out of curiosity?
The current Linux kernel is able to recognize zoned block devices and
provide some means for the user to see that a particular device is zoned.
For example, lsscsi will show "zbc" instead of "disk" for zoned devices.
Another useful value is the "zoned" sysfs attribute that carries the
zoned model of the drive. Without this patch, the attachment methods
mentioned above present host-managed drives as regular drives at the
guest system. There is no way for the user to figure out that they are
dealing with a ZBD besides starting I/O and getting "unaligned write"
error.

The folks who designed ZAC/ZBC were very careful about this not to
happen and this doesn't happen on bare metal. Host-managed drives have
a distinctive SCSI device type, 0x14, and old kernels without zoned
device support simply are not be able to classify these drives during
the device scan. The kernels with ZBD support are able to recognize
a host-managed drive by its SCSI type and read some additional
protocol-specific info from the drive that is necessary for the kernel
to support it (how? see http://zonedstorage.io/linux/sched/).
In QEMU, this SCSI device type mechanism currently only works for
attachment methods that directly pass SCSI commands to the host OS
during the initial device scan, i.e. scsi-block and scsi-generic.
All other methods should be disabled until a meaningful way of handling
ZBDs is developed for each of them (or disabled permanently for "legacy"
attachment methods).

> 
> Naively, it seems strange to me that you'd have something that presents
> itself as a block device but can't be used like one. Usually I expect to
> see new features / types of devices used inefficiently when we aren't
> aware of a special attribute/property they have, but not create data
> corruption.
Data corruption can theoretically happen, for example, if a regular hard
drive is accidentally swapped for a zoned one in a complex environment
under I/O. Any environment where this can potentially be a problem must
have udev rules defined to prevent this situation. Without this type of
patch, these udev rules will not work.
> 
> The only reason I ask is because it seems odd that you need to add a
> special flag to e.g. legacy IDE devices that explicitly says they don't
> support zoned block devices -- instead of adding flags to virtio devices
> that say they explicitly do support that feature set.
The initial version of the patch set had some bits of code added in the
drivers that are not capable of supporting zoned devices to check if the
device is zoned and abort if it is. Kevin and Paolo suggested the current
approach and I think it's a lot cleaner than the initial attempt since it
minimizes the necessary changes across the whole set of block drivers. The
flag is a true/false setting that is set individually by each driver. It
is in line with two existing flags in blkconf_apply_backend_options(),
"readonly" and "resizable". There is no "default" setting for any of these.
> 
> --js
> 
> > This patch set adds code to check if the backing device that is being
> > opened is a zoned Host Managed device. If this is the case, the patch
> > prohibits attaching such device for all use cases lacking proper
> > zoned support.
> > 
> > Host Aware zoned block devices are designed to work as regular block
> > devices at a guest system that does not support ZBD. Therefore, this
> > patch set doesn't prohibit attachment of Host Aware devices.
> > 
> > Considering that there is still a couple of different working ways
> > to attach a ZBD, this patch set provides a reasonable short-term
> > solution for this problem. What about long term?
> > 
> > It appears to be beneficial to add proper ZBD support to virtio-blk.
> > In order to support this use case properly, some virtio-blk protocol
> > changes will be necessary. They are needed to allow the host code to
> > propagate some ZBD properties that are required for virtio guest
> > driver to configure the guest block device as ZBD, such as zoned
> > device model, zone size and the total number of zones. Further, some
> > support needs to be added for REPORT ZONES command as well as for zone
> > operations, such as OPEN ZONE, CLOSE ZONE, FINISH ZONE and RESET ZONE.
> > 
> > These additions to the protocol are relatively straightforward, but
> > they need to be approved by the virtio TC and the whole process may
> > take some time.
> > 
> > ZBD support for virtio-scsi-pci/scsi-disk and virtio-scsi-pci/scsi-hd
> > does not seem as necessary. Users will be expected to attach zoned
> > block devices via virtio-scsi-pci/scsi-block instead.
> > 
> > This patch set contains some Linux-specific code. This code is
> > necessary to obtain Zoned Block Device model value from Linux sysfs.
> > 
> > History:
> > 
> > v1 -> v2:
> > - rework the code to be permission-based
> > - always allow Host Aware devices to be attached
> > - add fix for Host Aware attachments aka RCAP output snoop
> > 
> > v2 -> v3:
> > - drop the patch for RCAP output snoop - merged separately
> > 
> > 
> > Dmitry Fomichev (4):
> >   block: Add zoned device model property
> >   raw: Recognize zoned backing devices
> >   block/ide/scsi: Set BLK_PERM_SUPPORT_ZONED
> >   raw: Don't open ZBDs if backend can't handle them
> > 
> >  block.c                   | 19 +++++++++
> >  block/file-posix.c        | 88 +++++++++++++++++++++++++++++++++------
> >  block/raw-format.c        |  8 ++++
> >  hw/block/block.c          |  8 +++-
> >  hw/block/fdc.c            |  4 +-
> >  hw/block/nvme.c           |  2 +-
> >  hw/block/virtio-blk.c     |  2 +-
> >  hw/block/xen-block.c      |  2 +-
> >  hw/ide/qdev.c             |  2 +-
> >  hw/scsi/scsi-disk.c       | 13 +++---
> >  hw/scsi/scsi-generic.c    |  2 +-
> >  hw/usb/dev-storage.c      |  2 +-
> >  include/block/block.h     | 21 +++++++++-
> >  include/block/block_int.h |  4 ++
> >  include/hw/block/block.h  |  3 +-
> >  15 files changed, 150 insertions(+), 30 deletions(-)
> >