| Message ID | 20171226025247.11082-3-famz@redhat.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 2017-12-26 03:52, Fam Zheng wrote: > Signed-off-by: Fam Zheng <famz@redhat.com> > Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> > Reviewed-by: Kashyap Chamarthy <kchamart@redhat.com> > Signed-off-by: Kevin Wolf <kwolf@redhat.com> > --- > qemu-img.texi | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/qemu-img.texi b/qemu-img.texi > index 60a0e080c6..e83e140f7a 100644 > --- a/qemu-img.texi > +++ b/qemu-img.texi > @@ -86,6 +86,15 @@ exclusive with the @var{-O} parameters. It is currently required to also use > the @var{-n} parameter to skip image creation. This restriction may be relaxed > in a future release. > > +@item --force-share (-U) > + So the previous patch makes the use of blank lines consistent and this one breaks it again? :-) > +If specified, @code{qemu-img} will open the image with shared permissions, > +which makes it less likely to conflict with a running guest's permissions due > +to image locking. For example, this can be used to get the image information > +(with 'info' subcommand) when the image is used by a running guest. Note that > +this could produce inconsistent results because of concurrent metadata changes, > +etc. This option is only allowed when opening images in read-only mode. I personally don't quite like the "makes it less likely to conflict", because that makes it sound like qemu would be stupid and need a nudge in the right direction -- when it's actually the user who does something a bit risky (and qemu is right in forbidding it by default). But since it's only a read-only thing, I won't actually object to it. (Maybe it should document more exactly what's happening, i.e. that this option will allow concurrent writers (as a standard user, I wouldn't know what "shared permissions" is supposed to mean).) Max > + > @item --backing-chain > will enumerate information about backing files in a disk image chain. Refer > below for further description. >
On Mon, Jan 29, 2018 at 05:01:41PM +0100, Max Reitz wrote: > On 2017-12-26 03:52, Fam Zheng wrote: [...] > So the previous patch makes the use of blank lines consistent and this > one breaks it again? :-) > > > +If specified, @code{qemu-img} will open the image with shared permissions, > > +which makes it less likely to conflict with a running guest's permissions due > > +to image locking. For example, this can be used to get the image information > > +(with 'info' subcommand) when the image is used by a running guest. Note that > > +this could produce inconsistent results because of concurrent metadata changes, > > +etc. This option is only allowed when opening images in read-only mode. > > I personally don't quite like the "makes it less likely to conflict", > because that makes it sound like qemu would be stupid and need a nudge > in the right direction -- when it's actually the user who does something > a bit risky (and qemu is right in forbidding it by default). But since > it's only a read-only thing, I won't actually object to it. > > (Maybe it should document more exactly what's happening, i.e. that this > option will allow concurrent writers (as a standard user, I wouldn't > know what "shared permissions" is supposed to mean).) Eerie -- Although I reviewed it, I was just mulling over this wording yesterday (while I was tweaking the wording of '--force-share' on a slide for a public conference). Indeed, "concurrent writers" is much clearer. [...]
On Tue, Jan 30, 2018 at 12:01 AM, Max Reitz <mreitz@redhat.com> wrote: > On 2017-12-26 03:52, Fam Zheng wrote: >> Signed-off-by: Fam Zheng <famz@redhat.com> >> Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com> >> Reviewed-by: Kashyap Chamarthy <kchamart@redhat.com> >> Signed-off-by: Kevin Wolf <kwolf@redhat.com> >> --- >> qemu-img.texi | 9 +++++++++ >> 1 file changed, 9 insertions(+) >> >> diff --git a/qemu-img.texi b/qemu-img.texi >> index 60a0e080c6..e83e140f7a 100644 >> --- a/qemu-img.texi >> +++ b/qemu-img.texi >> @@ -86,6 +86,15 @@ exclusive with the @var{-O} parameters. It is currently required to also use >> the @var{-n} parameter to skip image creation. This restriction may be relaxed >> in a future release. >> >> +@item --force-share (-U) >> + > > So the previous patch makes the use of blank lines consistent and this > one breaks it again? :-) Good point, will fix. > >> +If specified, @code{qemu-img} will open the image with shared permissions, >> +which makes it less likely to conflict with a running guest's permissions due >> +to image locking. For example, this can be used to get the image information >> +(with 'info' subcommand) when the image is used by a running guest. Note that >> +this could produce inconsistent results because of concurrent metadata changes, >> +etc. This option is only allowed when opening images in read-only mode. > > I personally don't quite like the "makes it less likely to conflict", > because that makes it sound like qemu would be stupid and need a nudge > in the right direction -- when it's actually the user who does something > a bit risky (and qemu is right in forbidding it by default). But since > it's only a read-only thing, I won't actually object to it. > > (Maybe it should document more exactly what's happening, i.e. that this > option will allow concurrent writers (as a standard user, I wouldn't > know what "shared permissions" is supposed to mean).) Makes sense to me. Sending v6. Fam
diff --git a/qemu-img.texi b/qemu-img.texi index 60a0e080c6..e83e140f7a 100644 --- a/qemu-img.texi +++ b/qemu-img.texi @@ -86,6 +86,15 @@ exclusive with the @var{-O} parameters. It is currently required to also use the @var{-n} parameter to skip image creation. This restriction may be relaxed in a future release. +@item --force-share (-U) + +If specified, @code{qemu-img} will open the image with shared permissions, +which makes it less likely to conflict with a running guest's permissions due +to image locking. For example, this can be used to get the image information +(with 'info' subcommand) when the image is used by a running guest. Note that +this could produce inconsistent results because of concurrent metadata changes, +etc. This option is only allowed when opening images in read-only mode. + @item --backing-chain will enumerate information about backing files in a disk image chain. Refer below for further description.