[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
signature.asc
Description: OpenPGP digital signature
[Qemu-block] [PATCH v2 4/9] block: Set BDRV_REQ_WRITE_UNCHANGED for COR writes, Max Reitz, 2018/04/21
[Qemu-block] [PATCH v2 5/9] block/quorum: Support BDRV_REQ_WRITE_UNCHANGED, Max Reitz, 2018/04/21
[Qemu-block] [PATCH v2 6/9] block: Support BDRV_REQ_WRITE_UNCHANGED in filters, Max Reitz, 2018/04/21
[Qemu-block] [PATCH v2 7/9] iotests: Clean up wrap image in 197, Max Reitz, 2018/04/21
[Qemu-block] [PATCH v2 8/9] iotests: Copy 197 for COR filter driver, Max Reitz, 2018/04/21
[Qemu-block] [PATCH v2 9/9] iotests: Add test for COR across nodes, Max Reitz, 2018/04/21