qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [Qemu-block] [PATCH] block: Simplify bdrv_can_write_zer


From: Eric Blake
Subject: Re: [Qemu-devel] [Qemu-block] [PATCH] block: Simplify bdrv_can_write_zeroes_with_unmap()
Date: Tue, 6 Feb 2018 13:28:41 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2

On 01/29/2018 05:08 AM, Stefan Hajnoczi wrote:
On Fri, Jan 26, 2018 at 01:34:39PM -0600, Eric Blake wrote:
We don't need the can_write_zeroes_with_unmap field in
BlockDriverInfo, because it is redundant information with
supported_zero_flags & BDRV_REQ_MAY_UNMAP.  Note that
BlockDriverInfo and supported_zero_flags are both per-device
settings, rather than global state about the driver as a
whole, which means one or both of these bits of information
can already be conditional.  Let's audit how they were set:

...
Simplify the code by moving the conditional into
supported_zero_flags for all drivers, then dropping the
now-unused BDI field.  For callers that relied on
bdrv_can_write_zeroes_with_unmap(), we return the same
per-device settings for drivers that had conditions (no
observable change in behavior there); and can now return
true (instead of false) for drivers that support passthrough
(for example, the commit driver) which gives those drivers
the same fix as nbd just got in bca80059e.  For callers that
relied on supported_zero_flags, we now have a few more places
that can avoid a wasted call to pwrite_zeroes() that will
just fail with ENOTSUP.

Suggested-by: Paolo Bonzini <address@hidden>
Signed-off-by: Eric Blake <address@hidden>

---
The commit id mentioned above is dependent on me not having to respin
my latest NBD pull request:

Based-on: <address@hidden>
([PULL 0/8] NBD patches through 26 Jan)

Reviewed-by: Stefan Hajnoczi <address@hidden>


Thanks.

Since this patch was discovered in relation to NBD code, I'm fine taking it through my NBD queue; but it's also more generic to the block layer, so I'm also fine if one of the other block maintainers grabs it first through their tree.

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



reply via email to

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