Re: [Qemu-devel] [PATCH v2 3/9] block: Add BDRV_REQ_WRITE_UNCHANGED flag

[Kevin Wolf <kwolf@redhat.com>]

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

Am 26.04.2018 um 04:12 hat Eric Blake geschrieben:
> On 04/25/2018 10:08 AM, Max Reitz wrote:
> 
> > 
> >> Also, that does raise the question of whether you have more work to
> >> support write-zero requests with WRITE_UNCHANGED (which indeed sounds
> >> like something plausible to support).
> > 
> > I'm afraid I don't quite understand the question.
> > BDRV_REQ_WRITE_UNCHANGED support is usually rather simple because as
> > said above it is only needed by drivers that rely on their parent to
> > request the permissions, i.e. filter drivers.  Since filter drivers just
> > forward the requests, all they have to do is retain the
> > BDRV_REQ_WRITE_UNCHANGED flag, be it a zero write or a normal write.
> 
> I'm trying to figure out if BDRV_REQ_WRITE_UNCHANGED makes sense for
> bdrv_co_pwrite_zeroes as well as bdrv_co_pwrite. I think the answer is
> yes (if we know the guest already reads zeroes, but need to write to the
> protocol layer anyways because of a commit operation, then mixing both
> BDRV_REQ_WRITE_UNCHANGED and BDRV_REQ_ZERO_WRITE to the block layer
> makes sense, and supported_zero_flags should indeed pass
> BDRV_REQ_WRITE_UNCHANGED on to a driver.

Yes, that makes sense to me. (Except that commit isn't WRITE_UNCHANGED,
but streaming is.)

> > It would be more complicated for format drivers, because they would have
> > to verify that the incoming unchanged write actually ends up as an
> > unchanged write in their file.  But we have already recognized that that
> > would be too much to ask and that format drivers may want to generally
> > just write anything to their child if it's writable (even regardless of
> > whether the grandparent issues writes to the format driver node), so
> > they always grab a WRITE permission on their file if possible.
> > Therefore, they do not have to support this request flag.
> 
> So qcow2 doesn't have to support the flag, but file-posix.c might want
> to.  Or are you saying that only filter drivers need to advertise
> support for the flag?

Essentially a caller of bdrv_co_pwritev() must pass the flag if it wants
to write to a child for which it doesn't have BLK_PERM_WRITE.

This is potentially true for filter drivers if their parent does the
same (because we don't let filter drivers take BLK_PERM_WRITE
unconditionally, but only if one of their parents requests it on the
filter node).

In order to be able to rightfully set BDRV_REQ_WRITE_UNCHANGED for its
own requests, however, the child node must make sure that the parent
request it is processing already had the flag, i.e. it must support
BDRV_REQ_WRITE_UNCHANGED.

In contrast, qcow2 and other format drivers never need to send
BDRV_REQ_WRITE_UNCHANGED requests to their children (because they always
take BLK_PERM_WRITE for writable images anyway), so they don't have a
use for the flag and therefore don't need to advertise support for it.

This means that after putting a filter driver between a node and its
read-only (or write-unchanged-only, to be precise) parent, that node may
still be shared with users that don't tolerate a writer, but putting a
format driver above it will fail while that other user is still
attached. This is the expected behaviour.

(And if you think about it, there is no reason for format drivers to
ever send a write unchanged request: Something like image streaming is
about the backing chain and doesn't exist for the file child. So if the
content really doesn't change, the format driver just shouldn't send the
request at all.)

Kevin

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]