qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Max Reitz <mreitz@redhat.com>
Cc: qemu-block@nongnu.org, eblake@redhat.com, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [RFC PATCH 10/11] qcow2: Store data file name in the image
Date: Tue, 19 Feb 2019 10:04:31 +0100	[thread overview]
Message-ID: <20190219090431.GD4727@localhost.localdomain> (raw)
In-Reply-To: <0e4a0d3a-832b-e8aa-7ea0-acce96e513d5@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 4542 bytes --]

Am 19.02.2019 um 01:18 hat Max Reitz geschrieben:
> On 31.01.19 18:55, Kevin Wolf wrote:
> > Rather than requiring that the external data file node is passed
> > explicitly when creating the qcow2 node, store the filename in the
> > designated header extension during .bdrv_create and read it from there
> > as a default during .bdrv_open.
> > 
> > Signed-off-by: Kevin Wolf <kwolf@redhat.com>
> > ---
> >  block/qcow2.h              |  1 +
> >  block/qcow2.c              | 69 +++++++++++++++++++++++++++++++++++++-
> >  tests/qemu-iotests/082.out | 27 +++++++++++++++
> >  3 files changed, 96 insertions(+), 1 deletion(-)
> 
> [...]
> 
> > diff --git a/block/qcow2.c b/block/qcow2.c
> > index 6cf862e8b9..4959bf16a4 100644
> > --- a/block/qcow2.c
> > +++ b/block/qcow2.c
> > @@ -398,6 +398,20 @@ static int qcow2_read_extensions(BlockDriverState *bs, uint64_t start_offset,
> >  #endif
> >              break;
> >  
> > +        case QCOW2_EXT_MAGIC_DATA_FILE:
> > +        {
> > +            s->image_data_file = g_malloc0(ext.len + 1);
> > +            ret = bdrv_pread(bs->file, offset, s->image_data_file, ext.len);
> > +            if (ret < 0) {
> > +                error_setg_errno(errp, -ret, "ERROR: Could not data file name");
> 
> I think you accidentally a word.
> 
> > +                return ret;
> > +            }
> > +#ifdef DEBUG_EXT
> > +            printf("Qcow2: Got external data file %s\n", s->image_data_file);
> > +#endif
> > +            break;
> > +        }
> > +
> >          default:
> >              /* unknown magic - save it in case we need to rewrite the header */
> >              /* If you add a new feature, make sure to also update the fast
> > @@ -1444,7 +1458,18 @@ static int coroutine_fn qcow2_do_open(BlockDriverState *bs, QDict *options,
> >      /* Open external data file */
> >      if (s->incompatible_features & QCOW2_INCOMPAT_DATA_FILE) {
> >          s->data_file = bdrv_open_child(NULL, options, "data-file", bs,
> > -                                       &child_file, false, errp);
> > +                                       &child_file, false, &local_err);
> > +        if (!s->data_file) {
> > +            if (s->image_data_file) {
> > +                error_free(local_err);
> > +                local_err = NULL;
> 
> This looked a bit weird to me at first because I was wondering why you
> wouldn't just pass allow_none=true and then handle errors (by passing
> them on).  But right, we want to retry with a filename set, maybe that
> makes more sense of the options.

I think we want the normal error message for the !s->image_data_file
case. With allow_none=true, we would have to come up with a new one here
(in the else branch below).

> Hm.  But then again, do we really?  It matches what we do with backing
> files, but that does give at least me headaches from time to time.  How
> bad would it be to allow either passing all valid options through
> @options (which would make qcow2 ignore the string in the header), or
> use the filename given in the header alone?

You mean offering only one of the two ways to configure the node?

The 'data-file' runtime option is a must so that libvirt can build the
graph node by node (and possibly use file descriptor passing one day).
But having to specify the option every time is very unfriendly for human
users, so I think allowing to store the file name in the header is a
must, too.

> > +                s->data_file = bdrv_open_child(s->image_data_file, options,
> > +                                               "data-file", bs, &child_file,
> > +                                               false, errp);
> > +            } else {
> > +                error_propagate(errp, local_err);
> > +            }
> > +        }
> >          if (!s->data_file) {
> >              ret = -EINVAL;
> >              goto fail;
> 
> [...]
> 
> > @@ -3229,6 +3270,26 @@ static int coroutine_fn qcow2_co_create_opts(const char *filename, QemuOpts *opt
> >          goto finish;
> >      }
> >  
> > +    /* Create and open an external data file (protocol layer) */
> > +    val = qdict_get_try_str(qdict, BLOCK_OPT_DATA_FILE);
> > +    if (val) {
> > +        ret = bdrv_create_file(val, opts, errp);
> 
> I suppose taking an existing file is saved for later?

I think it's saved for the day that 'qemu-img create' is extended (or
replaced with an alternative) to provide the same functionality as QMP
blockdev-create.

Kevin

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

  reply	other threads:[~2019-02-19  9:05 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-31 17:55 [Qemu-devel] [RFC PATCH 00/11] qcow2: External data files Kevin Wolf
2019-01-31 17:55 ` [Qemu-devel] [RFC PATCH 01/11] qcow2: Extend spec for external " Kevin Wolf
2019-01-31 18:43   ` Eric Blake
2019-01-31 21:44     ` [Qemu-devel] [Qemu-block] " Nir Soffer
2019-02-01 10:29       ` Kevin Wolf
2019-02-01 10:21     ` [Qemu-devel] " Kevin Wolf
2019-02-01 16:17       ` Eric Blake
2019-02-01 16:53         ` Kevin Wolf
2019-01-31 17:55 ` [Qemu-devel] [RFC PATCH 02/11] qcow2: Basic definitions " Kevin Wolf
2019-01-31 17:55 ` [Qemu-devel] [RFC PATCH 03/11] qcow2: Pass bs to qcow2_get_cluster_type() Kevin Wolf
2019-01-31 17:55 ` [Qemu-devel] [RFC PATCH 04/11] qcow2: Prepare qcow2_get_cluster_type() for external data file Kevin Wolf
2019-01-31 17:55 ` [Qemu-devel] [RFC PATCH 05/11] qcow2: Prepare count_contiguous_clusters() " Kevin Wolf
2019-01-31 17:55 ` [Qemu-devel] [RFC PATCH 06/11] qcow2: Don't assume 0 is an invalid cluster offset Kevin Wolf
2019-02-18 23:13   ` Max Reitz
2019-02-19  8:45     ` Kevin Wolf
2019-02-22 14:09       ` Max Reitz
2019-01-31 17:55 ` [Qemu-devel] [RFC PATCH 07/11] qcow2: External file I/O Kevin Wolf
2019-02-18 23:36   ` Max Reitz
2019-01-31 17:55 ` [Qemu-devel] [RFC PATCH 08/11] qcow2: Add basic data-file infrastructure Kevin Wolf
2019-01-31 18:44   ` Eric Blake
2019-02-01 10:30     ` Kevin Wolf
2019-02-18 23:57   ` Max Reitz
2019-02-19  8:51     ` Kevin Wolf
2019-02-22 14:12       ` Max Reitz
2019-02-22 15:38         ` Kevin Wolf
2019-02-22 15:45           ` Max Reitz
2019-01-31 17:55 ` [Qemu-devel] [RFC PATCH 09/11] qcow2: Creating images with external data file Kevin Wolf
2019-01-31 17:55 ` [Qemu-devel] [RFC PATCH 10/11] qcow2: Store data file name in the image Kevin Wolf
2019-01-31 22:39   ` Nir Soffer
2019-02-19  0:18   ` Max Reitz
2019-02-19  9:04     ` Kevin Wolf [this message]
2019-02-22 14:16       ` Max Reitz
2019-02-22 15:35         ` Kevin Wolf
2019-02-22 15:43           ` Max Reitz
2019-02-22 16:06             ` Kevin Wolf
2019-02-22 16:22               ` Max Reitz
2019-01-31 17:55 ` [Qemu-devel] [RFC PATCH 11/11] qcow2: Add data file to ImageInfoSpecificQCow2 Kevin Wolf
2019-02-19  0:47   ` Max Reitz
2019-02-19  9:17     ` Kevin Wolf
2019-02-19 15:49       ` Eric Blake
2019-02-22 13:51       ` Max Reitz
2019-02-22 15:57         ` Kevin Wolf
2019-02-22 16:13           ` Max Reitz
2019-02-22 16:29             ` Kevin Wolf
2019-01-31 21:39 ` [Qemu-devel] [Qemu-block] [RFC PATCH 00/11] qcow2: External data files Nir Soffer
2019-02-19  0:49 ` [Qemu-devel] " Max Reitz

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190219090431.GD4727@localhost.localdomain \
    --to=kwolf@redhat.com \
    --cc=eblake@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).