Eric Blake <ebl...@redhat.com> writes: > On 1/24/20 4:34 AM, David Edmondson wrote: >> In many cases the target of a convert operation is a newly provisioned >> target that the user knows is blank (filled with zeroes). In this >> situation there is no requirement for qemu-img to wastefully zero out >> the entire device. >> >> Add a new option, --target-is-zero, allowing the user to indicate that >> an existing target device is already zero filled. >> >> Signed-off-by: David Edmondson <david.edmond...@oracle.com> >> --- >> qemu-img-cmds.hx | 4 ++-- >> qemu-img.c | 25 ++++++++++++++++++++++--- >> qemu-img.texi | 4 ++++ >> 3 files changed, 28 insertions(+), 5 deletions(-) > > I'm working up a patch series that tries to auto-set this flag without > user interaction where possible (for example, if lseek(fd, 0, SEEK_DATA) > returns EOF, or if fstat() reports 0 blocks allocated, or if qcow2 sees > no L2 tables allocated, or a proposed extension to NBD passes on the > same...). I may rebase my series on top of your patch and tweak things > in yours accordingly. > > But as it stands, the idea makes sense to me; even if we add ways for > some images to efficiently report initial state (and our existing > bdrv_has_zero_init() is NOT such a method), there are enough other > scenarios where the knob will be the only way to let qemu-img know the > intent.
Having qemu-img figure things out on its own is obviously desirable, but I agree that there are enough cases where this won't be possible and, given the resulting performance improvement, it will still be useful to allow the caller to force things. >> + case OPTION_TARGET_IS_ZERO: >> + /* >> + * The user asserting that the target is blank has the >> + * same effect as the target driver supporting zero >> + * initialisation. > > Hmm. A git grep shows that 'initialization' has 200 hits, > 'initialisation' has only 29. But I think it's a US vs. UK thing, so I > don't care which spelling you use. Yes, it's British English spelling. It was unconscious - I'll switch if there is an existing policy. > Reviewed-by: Eric Blake <ebl...@redhat.com> Thanks. If the conversion of the documentation to rST is imminent then I'll wait for that before submitting a followup with corresponding changes applied to the new docs. dme. -- I'd come on over but I haven't got a raincoat.
