All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Blake <eblake@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: qemu-devel@nongnu.org, qemu-stable@nongnu.org,
	Stefan Hajnoczi <stefanha@redhat.com>,
	Fam Zheng <famz@redhat.com>, Max Reitz <mreitz@redhat.com>,
	"open list:Block I/O path" <qemu-block@nongnu.org>
Subject: Re: [Qemu-devel] [PATCH] block: Don't lose FUA flag during ZERO_WRITE fallback
Date: Mon, 2 May 2016 09:42:59 -0600	[thread overview]
Message-ID: <57277583.1030209@redhat.com> (raw)
In-Reply-To: <20160502153529.GE4882@noname.redhat.com>

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

On 05/02/2016 09:35 AM, Kevin Wolf wrote:
> Am 30.04.2016 um 23:48 hat Eric Blake geschrieben:
>> NBD has situations where it can support FUA but not ZERO_WRITE;
>> when that happens, the generic block layer fallback was losing
>> the FUA flag.  The problem of losing flags unrelated to
>> ZERO_WRITE has been latent in bdrv_co_do_write_zeroes() since
>> aa7bfbff, but back then, it did not matter because there was no
>> FUA flag.  But ever since 93f5e6d8 added bdrv_co_writev_flags(),
>> the loss of flags can impact correctness.
>>

>> +++ b/block/io.c
>> @@ -1213,7 +1213,8 @@ static int coroutine_fn bdrv_co_do_write_zeroes(BlockDriverState *bs,
>>              qemu_iovec_init_external(&qiov, &iov, 1);
>>
>>              ret = bdrv_driver_pwritev(bs, sector_num * BDRV_SECTOR_SIZE,
>> -                                      num * BDRV_SECTOR_SIZE, &qiov, 0);
>> +                                      num * BDRV_SECTOR_SIZE, &qiov,
>> +                                      flags & ~BDRV_REQ_ZERO_WRITE);
> 
> This is a good change, but it's only in the fallback code. If we succeed
> here:
> 
>     if (drv->bdrv_co_write_zeroes) {
>         ret = drv->bdrv_co_write_zeroes(bs, sector_num, num, flags);
>     }
> 
> then we still don't get the necessary flush unless the driver's
> .bdrv_co_write_zeroes() implementation explicitly handles FUA. As far as
> I know, we don't have any driver that implements FUA there.

NBD will, once we get to that part of my series.

But I see what you're saying: since we already emulate FUA for all
drivers where .supported_write_flags does not include BDRV_REQ_FUA
during bdrv_driver_pwritev(), we should also emulate it here for all the
same drivers (and any driver that DOES advertise BDRV_REQ_FUA as
supported as well as a write_zeroes callback should be fixed to honor
it).  I'll do that in v2, which I guess means I should post it at the
same time as my work for making .supported_write_flags a per-bds rather
than per-driver designation.

-- 
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-02 15:44 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 [this message]
2016-05-02 17:14     ` Eric Blake
2016-05-03  7:55       ` Kevin Wolf
2016-05-03 12:28         ` Eric Blake

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=57277583.1030209@redhat.com \
    --to=eblake@redhat.com \
    --cc=famz@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mreitz@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.