qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eric Blake
Subject: Re: [Qemu-block] [Qemu-devel] [PATCH v2 3/9] block: Add BDRV_REQ_WRITE_UNCHANGED flag
Date: Wed, 25 Apr 2018 21:12:54 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0

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.

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

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]