On Thu, Apr 10, 2025 at 08:04:50PM -0500, Eric Blake wrote:
> When mirroring images, it makes sense for the destination to be sparse
> even if it was not connected with "discard":"unmap"; the only time the
> destination should be fully allocated is if the user pre-allocated it,
> or if the source was not sparse.
>
> Eric Blake (6):
> mirror: Skip pre-zeroing destination if it is already zero
> file-posix: Allow lseek at offset 0 when !want_zero
> mirror: Skip writing zeroes when target is already zero
> block: Expand block status mode from bool to enum
> file-posix: Recognize blockdev-create file as starting all zero
> tests: Add iotest mirror-sparse for recent patches
Responding here to point out that in
https://issues.redhat.com/browse/RHEL-82906, Peter Krempa identified
that it was Nir's earlier patch:
> commit d05ae948cc887054495977855b0859d0d4ab2613
> Author: Nir Soffer <nsoffer@redhat.com>
> Date: Fri Jun 28 23:20:58 2024 +0300
>
> Consider discard option when writing zeros
>
> When opening an image with discard=off, we punch hole in the image when
> writing zeroes, making the image sparse. This breaks users that want to
> ensure that writes cannot fail with ENOSPACE by using fully allocated
> images[1].
>
> bdrv_co_pwrite_zeroes() correctly disables BDRV_REQ_MAY_UNMAP if we
> opened the child without discard=unmap or discard=on. But we don't go
> through this function when accessing the top node. Move the check down
> to bdrv_co_do_pwrite_zeroes() which seems to be used in all code paths.
>
> This change implements the documented behavior, punching holes only when
> opening the image with discard=on or discard=unmap. This may not be the
> best default but can improve it later.
> ...
that changed qemu's behavior last year to be closer to its documentation.
It raises the question: should we change the default for "discard"
from "ignore" (what we currently have, where write zeroes defaults to
full allocation if you didn't request otherwise - but where this patch
series demonstrates that we can still be careful to avoid writing
zeroes to something that already reads as zeroes as a way to preserve
sparseness) to "unmap" (ie. we would favor sparse files by default,
but where you can still opt-in to full allocation)?
What are the policies on changing defaults? Do we have to issue a
deprecation notice for any block device opened without specifying a
"discard" policy, and go through a couple of release cycles, so that
two releases down the road we can change the "discard" parameter from
optional to mandatory, and then even later switch it back to optional
but with a new default?
--
Eric Blake, Principal Software Engineer
Red Hat, Inc.
Virtualization: qemu.org | libguestfs.org