* [PATCH] docs: Better mention of qemu-img amend limitations
@ 2020-09-23 20:37 Eric Blake
2020-09-23 21:56 ` Nir Soffer
2020-11-13 9:49 ` Kevin Wolf
0 siblings, 2 replies; 6+ messages in thread
From: Eric Blake @ 2020-09-23 20:37 UTC (permalink / raw)
To: qemu-devel; +Cc: kwolf, qemu-block
Missed during merge resolution of commit bc5ee6da71.
Signed-off-by: Eric Blake <eblake@redhat.com>
---
docs/tools/qemu-img.rst | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/docs/tools/qemu-img.rst b/docs/tools/qemu-img.rst
index c35bd6482203..2b5891b54db7 100644
--- a/docs/tools/qemu-img.rst
+++ b/docs/tools/qemu-img.rst
@@ -265,6 +265,10 @@ Command description:
--force allows some unsafe operations. Currently for -f luks, it allows to
erase the last encryption key, and to overwrite an active encryption key.
+ The set of options that can be amended are dependent on the image
+ format, but note that amending the backing chain relationship should
+ instead be performed with ``qemu-img rebase``.
+
.. option:: bench [-c COUNT] [-d DEPTH] [-f FMT] [--flush-interval=FLUSH_INTERVAL] [-i AIO] [-n] [--no-drain] [-o OFFSET] [--pattern=PATTERN] [-q] [-s BUFFER_SIZE] [-S STEP_SIZE] [-t CACHE] [-w] [-U] FILENAME
Run a simple sequential I/O benchmark on the specified image. If ``-w`` is
--
2.28.0
^ permalink raw reply related [flat|nested] 6+ messages in thread
* Re: [PATCH] docs: Better mention of qemu-img amend limitations
2020-09-23 20:37 [PATCH] docs: Better mention of qemu-img amend limitations Eric Blake
@ 2020-09-23 21:56 ` Nir Soffer
2020-10-20 15:44 ` Eric Blake
2020-11-13 9:49 ` Kevin Wolf
1 sibling, 1 reply; 6+ messages in thread
From: Nir Soffer @ 2020-09-23 21:56 UTC (permalink / raw)
To: Eric Blake; +Cc: Kevin Wolf, QEMU Developers, qemu-block
On Wed, Sep 23, 2020 at 11:38 PM Eric Blake <eblake@redhat.com> wrote:
>
> Missed during merge resolution of commit bc5ee6da71.
>
> Signed-off-by: Eric Blake <eblake@redhat.com>
> ---
> docs/tools/qemu-img.rst | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/docs/tools/qemu-img.rst b/docs/tools/qemu-img.rst
> index c35bd6482203..2b5891b54db7 100644
> --- a/docs/tools/qemu-img.rst
> +++ b/docs/tools/qemu-img.rst
> @@ -265,6 +265,10 @@ Command description:
> --force allows some unsafe operations. Currently for -f luks, it allows to
> erase the last encryption key, and to overwrite an active encryption key.
>
> + The set of options that can be amended are dependent on the image
> + format, but note that amending the backing chain relationship should
> + instead be performed with ``qemu-img rebase``.
Because of the backing format?
> +
> .. option:: bench [-c COUNT] [-d DEPTH] [-f FMT] [--flush-interval=FLUSH_INTERVAL] [-i AIO] [-n] [--no-drain] [-o OFFSET] [--pattern=PATTERN] [-q] [-s BUFFER_SIZE] [-S STEP_SIZE] [-t CACHE] [-w] [-U] FILENAME
>
> Run a simple sequential I/O benchmark on the specified image. If ``-w`` is
> --
> 2.28.0
>
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] docs: Better mention of qemu-img amend limitations
2020-09-23 21:56 ` Nir Soffer
@ 2020-10-20 15:44 ` Eric Blake
2020-11-12 21:10 ` Eric Blake
0 siblings, 1 reply; 6+ messages in thread
From: Eric Blake @ 2020-10-20 15:44 UTC (permalink / raw)
To: Nir Soffer; +Cc: Kevin Wolf, QEMU Developers, qemu-block
[-- Attachment #1.1.1: Type: text/plain, Size: 2255 bytes --]
On 9/23/20 4:56 PM, Nir Soffer wrote:
> On Wed, Sep 23, 2020 at 11:38 PM Eric Blake <eblake@redhat.com> wrote:
>>
>> Missed during merge resolution of commit bc5ee6da71.
>>
>> Signed-off-by: Eric Blake <eblake@redhat.com>
>> ---
>> docs/tools/qemu-img.rst | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/docs/tools/qemu-img.rst b/docs/tools/qemu-img.rst
>> index c35bd6482203..2b5891b54db7 100644
>> --- a/docs/tools/qemu-img.rst
>> +++ b/docs/tools/qemu-img.rst
>> @@ -265,6 +265,10 @@ Command description:
>> --force allows some unsafe operations. Currently for -f luks, it allows to
>> erase the last encryption key, and to overwrite an active encryption key.
>>
>> + The set of options that can be amended are dependent on the image
>> + format, but note that amending the backing chain relationship should
>> + instead be performed with ``qemu-img rebase``.
>
> Because of the backing format?
Sorry for not answering this earlier (and now this serves as a ping for
the patch):
Consider if you have:
Base.raw <- Overlay.qcow2
and want to rebase it to:
Base.qcow2 <- Overlay.qcow2
where Base.raw and Base.qcow2 contain identical guest-visible content.
The problem at hand is that 'qemu-amend' needs to know what the backing
format is both before the rebase (to know how to properly read the
existing image) and after the rebase (to ensure that future opens of
Overlay.qcow2 still properly read the backing format). But there is no
obvious command-line spelling to specify the difference between the
backing format pre-amend and the backing format post-amend. Maybe we
could add that, but I felt it was easier to just document that instead
of trying to amend the image (which involves multiple steps, and may
require upgrading/downgrading between v2 and v3, which in turn may
affect decisions on efficiency of representing regions of zero) at the
same time as the backing file/format, it's easier to just update the
backing file/format with a stand-alone command.
I can add that to the commit message, if the patch itself is reasonable.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
[-- Attachment #1.1.2: OpenPGP_0xA7A16B4A2527436A_and_old_rev.asc --]
[-- Type: application/pgp-keys, Size: 103475 bytes --]
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] docs: Better mention of qemu-img amend limitations
2020-10-20 15:44 ` Eric Blake
@ 2020-11-12 21:10 ` Eric Blake
0 siblings, 0 replies; 6+ messages in thread
From: Eric Blake @ 2020-11-12 21:10 UTC (permalink / raw)
To: Nir Soffer; +Cc: Kevin Wolf, QEMU Developers, qemu-block
Ping^2
On 10/20/20 10:44 AM, Eric Blake wrote:
> On 9/23/20 4:56 PM, Nir Soffer wrote:
>> On Wed, Sep 23, 2020 at 11:38 PM Eric Blake <eblake@redhat.com> wrote:
>>>
>>> Missed during merge resolution of commit bc5ee6da71.
>>>
>>> Signed-off-by: Eric Blake <eblake@redhat.com>
>>> ---
>>> docs/tools/qemu-img.rst | 4 ++++
>>> 1 file changed, 4 insertions(+)
>>>
>>> diff --git a/docs/tools/qemu-img.rst b/docs/tools/qemu-img.rst
>>> index c35bd6482203..2b5891b54db7 100644
>>> --- a/docs/tools/qemu-img.rst
>>> +++ b/docs/tools/qemu-img.rst
>>> @@ -265,6 +265,10 @@ Command description:
>>> --force allows some unsafe operations. Currently for -f luks, it allows to
>>> erase the last encryption key, and to overwrite an active encryption key.
>>>
>>> + The set of options that can be amended are dependent on the image
>>> + format, but note that amending the backing chain relationship should
>>> + instead be performed with ``qemu-img rebase``.
>>
>> Because of the backing format?
>
> Sorry for not answering this earlier (and now this serves as a ping for
> the patch):
>
> Consider if you have:
>
> Base.raw <- Overlay.qcow2
>
> and want to rebase it to:
>
> Base.qcow2 <- Overlay.qcow2
>
> where Base.raw and Base.qcow2 contain identical guest-visible content.
> The problem at hand is that 'qemu-amend' needs to know what the backing
> format is both before the rebase (to know how to properly read the
> existing image) and after the rebase (to ensure that future opens of
> Overlay.qcow2 still properly read the backing format). But there is no
> obvious command-line spelling to specify the difference between the
> backing format pre-amend and the backing format post-amend. Maybe we
> could add that, but I felt it was easier to just document that instead
> of trying to amend the image (which involves multiple steps, and may
> require upgrading/downgrading between v2 and v3, which in turn may
> affect decisions on efficiency of representing regions of zero) at the
> same time as the backing file/format, it's easier to just update the
> backing file/format with a stand-alone command.
>
> I can add that to the commit message, if the patch itself is reasonable.
>
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] docs: Better mention of qemu-img amend limitations
2020-09-23 20:37 [PATCH] docs: Better mention of qemu-img amend limitations Eric Blake
2020-09-23 21:56 ` Nir Soffer
@ 2020-11-13 9:49 ` Kevin Wolf
2020-11-13 13:40 ` Eric Blake
1 sibling, 1 reply; 6+ messages in thread
From: Kevin Wolf @ 2020-11-13 9:49 UTC (permalink / raw)
To: Eric Blake; +Cc: qemu-devel, qemu-block
Am 23.09.2020 um 22:37 hat Eric Blake geschrieben:
> Missed during merge resolution of commit bc5ee6da71.
>
> Signed-off-by: Eric Blake <eblake@redhat.com>
> ---
> docs/tools/qemu-img.rst | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/docs/tools/qemu-img.rst b/docs/tools/qemu-img.rst
> index c35bd6482203..2b5891b54db7 100644
> --- a/docs/tools/qemu-img.rst
> +++ b/docs/tools/qemu-img.rst
> @@ -265,6 +265,10 @@ Command description:
Adding a little more context:
> The set of options that can be amended are dependent on the image
> format, but note that amending the backing chain relationship should
> instead be performed with ``qemu-img rebase``.
>
> --force allows some unsafe operations. Currently for -f luks, it allows to
> erase the last encryption key, and to overwrite an active encryption key.
>
> + The set of options that can be amended are dependent on the image
> + format, but note that amending the backing chain relationship should
> + instead be performed with ``qemu-img rebase``.
> +
I think the problem is your local conflict resolution. This patch would
duplicate the paragraph.
Kevin
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH] docs: Better mention of qemu-img amend limitations
2020-11-13 9:49 ` Kevin Wolf
@ 2020-11-13 13:40 ` Eric Blake
0 siblings, 0 replies; 6+ messages in thread
From: Eric Blake @ 2020-11-13 13:40 UTC (permalink / raw)
To: Kevin Wolf; +Cc: qemu-devel, qemu-block
On 11/13/20 3:49 AM, Kevin Wolf wrote:
> Am 23.09.2020 um 22:37 hat Eric Blake geschrieben:
>> Missed during merge resolution of commit bc5ee6da71.
>>
>> Signed-off-by: Eric Blake <eblake@redhat.com>
>> ---
>> docs/tools/qemu-img.rst | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/docs/tools/qemu-img.rst b/docs/tools/qemu-img.rst
>> index c35bd6482203..2b5891b54db7 100644
>> --- a/docs/tools/qemu-img.rst
>> +++ b/docs/tools/qemu-img.rst
>> @@ -265,6 +265,10 @@ Command description:
>
> Adding a little more context:
>
>> The set of options that can be amended are dependent on the image
>> format, but note that amending the backing chain relationship should
>> instead be performed with ``qemu-img rebase``.
>>
>> --force allows some unsafe operations. Currently for -f luks, it allows to
>> erase the last encryption key, and to overwrite an active encryption key.
>>
>> + The set of options that can be amended are dependent on the image
>> + format, but note that amending the backing chain relationship should
>> + instead be performed with ``qemu-img rebase``.
>> +
>
> I think the problem is your local conflict resolution. This patch would
> duplicate the paragraph.
D'oh. Thanks for spotting that, patch withdrawn.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2020-11-13 13:43 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-23 20:37 [PATCH] docs: Better mention of qemu-img amend limitations Eric Blake
2020-09-23 21:56 ` Nir Soffer
2020-10-20 15:44 ` Eric Blake
2020-11-12 21:10 ` Eric Blake
2020-11-13 9:49 ` Kevin Wolf
2020-11-13 13:40 ` Eric Blake
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).