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
