Re: [Qemu-devel] [PATCH] block: Don't lose FUA flag during ZERO_WRITE fallback

[Eric Blake <eblake@redhat.com>]

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

On 05/02/2016 09:42 AM, Eric Blake wrote:
> 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.
>>>
> 

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

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.

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

It also looks like SCSI would benefit from a per-bds
supported_write_flags, as our iscsi_modesense_sync() is setting
iscsilun->dpofua conditionally; likewise, iscsi_co_writev_flags blindly
ignores BDRV_REQ_FUA if iscsilun->dpofua is not set.  Which means that
not all ISCSI devices support the FUA bit in WRITE(10/16) requests, and
that therefore we should not be blindly assuming that FUA worked on
those devices where it was not sensed.  So just like NBD, iscsi has
cases where we need an automatic FUA fallback at the block layer,
regardless of whether we also need the fallback for WRITESAME(10/16).

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