qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: Fam Zheng <famz@redhat.com>,
	"open list:Block I/O path" <qemu-block@nongnu.org>,
	qemu-stable@nongnu.org, qemu-devel@nongnu.org,
	Max Reitz <mreitz@redhat.com>,
	Stefan Hajnoczi <stefanha@redhat.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Subject: Re: [Qemu-devel] [PATCH] block: Don't lose FUA flag during ZERO_WRITE fallback
Date: Tue, 3 May 2016 06:28:15 -0600	[thread overview]
Message-ID: <5728995F.3040703@redhat.com> (raw)
In-Reply-To: <20160503075535.GB3917@noname.str.redhat.com>

[-- Attachment #1: Type: text/plain, Size: 2174 bytes --]

On 05/03/2016 01:55 AM, Kevin Wolf wrote:
>> And looking further, it looks like SCSI does NOT support FUA during
>> WRITESAME(10/16), only during WRITE(10/16).  Which means we probably
>> want to start having both .supported_write_flags AND
>> .supported_write_zero flags, so that at least the iscsi driver can
>> properly report that it does NOT natively support FUA on a write_zeroes
>> request.
> 
> Hm, not sure if it makes sense, but let me write that thought down:
> 
> You're going to convert .supported_write_flags to a function anyway.
> Instead of adding a second function, how about passing a set of flags
> there and the function returns a subset that it can support? For write
> zeroes with FUA you would pass in BDRV_REQ_ZERO_WRITE | BDRV_REQ_FUA and
> in this case the iscsi driver would return only BDRV_REQ_ZERO_WRITE.
> 
> If we ever decided to get rid of .bdrv_co_write_zeroes() and instead use
> .bdrv_co_pwritev() with BDRV_REQ_ZERO_WRITE, this would probably be the
> most consistent interface.

I'm currently leaning towards two flags rather than a function (the
flags are set during .bdrv_open(), and don't change during the life of
the BDS):

bs->supported_write_flags = BDRV_REQ_FUA;
bs->supported_zero_flags = BDRV_REQ_MAY_UNMAP; // | BDRV_REQ_FUA

and keeping the BDRV_REQ_ZERO_WRITE as a special case in the block layer
that chooses between .bdrv_co_write_zeroes() or .bdrv_driver_pwrite().
MAY_UNMAP makes no sense on a normal write, just as iscsi doesn't allow
FUA on a zero write, so having the two sets of valid flags according to
operations, as well as the two driver entries, seems to make the most
sense.  Then io.c, we ignore MAY_UNMAP where it is unsupported, and
emulate FUA on both write and write_zero as needed.

Of course, if we ever have a driver that can support everything through
a single entry, it could advertise supported_write_flags = BDRV_REQ_FUA
| BDRV_REQ_ZERO_WRITE | BDRV_REQ_MAY_UNMAP and provide only
.bdrv_driver_pwrite(), but I don't think that will be happening.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]

      reply	other threads:[~2016-05-03 12:29 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-30 21:48 [Qemu-devel] [PATCH] block: Don't lose FUA flag during ZERO_WRITE fallback Eric Blake
2016-05-02 15:35 ` Kevin Wolf
2016-05-02 15:42   ` Eric Blake
2016-05-02 17:14     ` Eric Blake
2016-05-03  7:55       ` Kevin Wolf
2016-05-03 12:28         ` Eric Blake [this message]

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=5728995F.3040703@redhat.com \
    --to=eblake@redhat.com \
    --cc=famz@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=qemu-stable@nongnu.org \
    --cc=stefanha@redhat.com \
    /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).