qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: John Snow <jsnow@redhat.com>
To: Dmitry Fomichev <dmitry.fomichev@wdc.com>,
	qemu-devel@nongnu.org, qemu-block@nongnu.org
Subject: Re: [Qemu-devel] [Qemu-block] [PATCH v3 0/4] virtio/block: handle zoned backing devices
Date: Thu, 25 Jul 2019 13:58:31 -0400	[thread overview]
Message-ID: <6d6bc169-49d8-8baf-99db-c99d066d59f6@redhat.com> (raw)
In-Reply-To: <20190723221940.25585-1-dmitry.fomichev@wdc.com>



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?

I've found this:
https://www.snia.org/sites/default/files/SDC/2016/presentations/smr/DamienLeMoal_ZBC-ZAC_Linux.pdf

It looks like ZAC/ZBC are new commands -- what happens if we just don't
use them, exactly?

> 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?

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.

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.

--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(-)
> 


  parent reply	other threads:[~2019-07-25 17:58 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-23 22:19 [Qemu-devel] [PATCH v3 0/4] virtio/block: handle zoned backing devices Dmitry Fomichev
2019-07-23 22:19 ` [Qemu-devel] [PATCH v3 1/4] block: Add zoned device model property Dmitry Fomichev
2019-07-23 22:19 ` [Qemu-devel] [PATCH v3 2/4] raw: Recognize zoned backing devices Dmitry Fomichev
2019-07-23 22:19 ` [Qemu-devel] [PATCH v3 3/4] block/ide/scsi: Set BLK_PERM_SUPPORT_ZONED Dmitry Fomichev
2019-07-23 22:19 ` [Qemu-devel] [PATCH v3 4/4] raw: Don't open ZBDs if backend can't handle them Dmitry Fomichev
2019-07-25 17:58 ` John Snow [this message]
2019-07-26 23:42   ` [Qemu-devel] [Qemu-block] [PATCH v3 0/4] virtio/block: handle zoned backing devices Dmitry Fomichev
2019-07-29 21:23     ` John Snow

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6d6bc169-49d8-8baf-99db-c99d066d59f6@redhat.com \
    --to=jsnow@redhat.com \
    --cc=dmitry.fomichev@wdc.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).