[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v2 3/9] block: Add BDRV_REQ_WRITE_UNCHANGED flag
From: |
Kevin Wolf |
Subject: |
Re: [Qemu-devel] [PATCH v2 3/9] block: Add BDRV_REQ_WRITE_UNCHANGED flag |
Date: |
Mon, 30 Apr 2018 10:41:16 +0200 |
User-agent: |
Mutt/1.9.1 (2017-09-22) |
Am 28.04.2018 um 13:19 hat Max Reitz geschrieben:
> On 2018-04-26 04:12, Eric Blake wrote:
> > 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.
>
> Well, why not.
>
> >> 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?
>
> It might make sense for file-posix, but when you think further, it
> wouldn't do anything in practice.
>
> First, if a protocol driver receives WRITE_UNCHANGED, there are two
> things it can do: If it knows that it only has very plain storage, it
> can just ignore the request because it won't do anything.
I think even a WRITE_UNCHANGED request is supposed to allocate a
currently unmappen block, so "very plain storage" probably has to mean
at least "supports neither backing files nor thin provisioning". Or you
would have to check the current allocation status first...
But I don't see a reason anyway why a WRITE_UNCHANGED request should end
up in the protocol layer.
Kevin
signature.asc
Description: PGP signature
[Qemu-devel] [PATCH v2 4/9] block: Set BDRV_REQ_WRITE_UNCHANGED for COR writes, Max Reitz, 2018/04/21
[Qemu-devel] [PATCH v2 6/9] block: Support BDRV_REQ_WRITE_UNCHANGED in filters, Max Reitz, 2018/04/21
[Qemu-devel] [PATCH v2 5/9] block/quorum: Support BDRV_REQ_WRITE_UNCHANGED, Max Reitz, 2018/04/21
[Qemu-devel] [PATCH v2 7/9] iotests: Clean up wrap image in 197, Max Reitz, 2018/04/21
[Qemu-devel] [PATCH v2 8/9] iotests: Copy 197 for COR filter driver, Max Reitz, 2018/04/21
[Qemu-devel] [PATCH v2 9/9] iotests: Add test for COR across nodes, Max Reitz, 2018/04/21
Re: [Qemu-devel] [PATCH v2 0/9] block: Add COR filter driver, Kevin Wolf, 2018/04/24
Re: [Qemu-devel] [PATCH v2 0/9] block: Add COR filter driver, Max Reitz, 2018/04/25