qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Stefano Garzarella <sgarzare@redhat.com>
Cc: dillaman@redhat.com, qemu-devel <qemu-devel@nongnu.org>,
	Josh Durgin <jdurgin@redhat.com>,
	qemu-block <qemu-block@nongnu.org>, Max Reitz <mreitz@redhat.com>
Subject: Re: [Qemu-devel] [PATCH RFC 1/1] block/rbd: increase dynamically the image size
Date: Wed, 17 Apr 2019 10:04:43 +0200	[thread overview]
Message-ID: <20190417080443.GA8330@localhost.localdomain> (raw)
In-Reply-To: <20190417073438.r57lemi6emu4x3ld@steredhat>

Am 17.04.2019 um 09:34 hat Stefano Garzarella geschrieben:
> On Mon, Apr 15, 2019 at 10:04:52AM +0200, Kevin Wolf wrote:
> > 
> > I think a potential actual use case could be persistent dirty bitmaps
> > for incremental backup. Though maybe that would be better served by
> > using the rbd image just as a raw external data file and keeping the
> > qcow2 metadata on a filesystem.
> 
> Thanks to point it out! I'll take a look to understand how to keep
> metadata separated from the data.

I'd consider the feature still experimental, but for local files, it
works like this:

    qemu-img create -f qcow2 -o data_file=test.raw test.qcow2 4G

And then just use test.qcow2. As long as you can put everything you need
into an rbd URL, the same approach should work. Otherwise, you may need
to use QMP blockdev-create on creation and possibly the data-file option
of the qcow2 driver for opening.

> > How fast is rbd_resize()? Does automatically resizing for every write
> > request actually work reasonably well in practice? If it does, there is
> > probably little reason not to allow it, even if the use cases are rather
> > obscure.
> 
> I'll try to measure the percentage of the time spent in the rbd_resize.
> 
> Another solution could be to pass to the rbd driver the virtual size of
> the image and resize it only one time also if the preallocation is
> disabled, because RBD will not allocate blocks but IIUC it only set the max
> size.
> 
> Do you think make sense? Is it feasible?

In theory yes, though it requires modification of every driver that
should be usable together with rbd (i.e. ideally all of the drivers). If
automatic resize works good enough, I'd prefer that.

Kevin

WARNING: multiple messages have this Message-ID (diff)
From: Kevin Wolf <kwolf@redhat.com>
To: Stefano Garzarella <sgarzare@redhat.com>
Cc: Josh Durgin <jdurgin@redhat.com>,
	dillaman@redhat.com, qemu-devel <qemu-devel@nongnu.org>,
	qemu-block <qemu-block@nongnu.org>, Max Reitz <mreitz@redhat.com>
Subject: Re: [Qemu-devel] [PATCH RFC 1/1] block/rbd: increase dynamically the image size
Date: Wed, 17 Apr 2019 10:04:43 +0200	[thread overview]
Message-ID: <20190417080443.GA8330@localhost.localdomain> (raw)
Message-ID: <20190417080443.0dOjedWWyuJY10bcTPUNnwLrbmGcNac9_d-FClsdOSw@z> (raw)
In-Reply-To: <20190417073438.r57lemi6emu4x3ld@steredhat>

Am 17.04.2019 um 09:34 hat Stefano Garzarella geschrieben:
> On Mon, Apr 15, 2019 at 10:04:52AM +0200, Kevin Wolf wrote:
> > 
> > I think a potential actual use case could be persistent dirty bitmaps
> > for incremental backup. Though maybe that would be better served by
> > using the rbd image just as a raw external data file and keeping the
> > qcow2 metadata on a filesystem.
> 
> Thanks to point it out! I'll take a look to understand how to keep
> metadata separated from the data.

I'd consider the feature still experimental, but for local files, it
works like this:

    qemu-img create -f qcow2 -o data_file=test.raw test.qcow2 4G

And then just use test.qcow2. As long as you can put everything you need
into an rbd URL, the same approach should work. Otherwise, you may need
to use QMP blockdev-create on creation and possibly the data-file option
of the qcow2 driver for opening.

> > How fast is rbd_resize()? Does automatically resizing for every write
> > request actually work reasonably well in practice? If it does, there is
> > probably little reason not to allow it, even if the use cases are rather
> > obscure.
> 
> I'll try to measure the percentage of the time spent in the rbd_resize.
> 
> Another solution could be to pass to the rbd driver the virtual size of
> the image and resize it only one time also if the preallocation is
> disabled, because RBD will not allocate blocks but IIUC it only set the max
> size.
> 
> Do you think make sense? Is it feasible?

In theory yes, though it requires modification of every driver that
should be usable together with rbd (i.e. ideally all of the drivers). If
automatic resize works good enough, I'd prefer that.

Kevin


  parent reply	other threads:[~2019-04-17  8:04 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-11 10:50 [Qemu-devel] [PATCH RFC 0/1] block/rbd: increase dynamically the image size Stefano Garzarella
2019-04-11 10:50 ` Stefano Garzarella
2019-04-11 10:50 ` [Qemu-devel] [PATCH RFC 1/1] " Stefano Garzarella
2019-04-11 10:50   ` Stefano Garzarella
2019-04-11 12:35   ` Jason Dillaman
2019-04-11 12:35     ` Jason Dillaman
2019-04-11 13:02     ` Stefano Garzarella
2019-04-11 13:02       ` Stefano Garzarella
2019-04-11 17:06       ` Jason Dillaman
2019-04-11 17:06         ` Jason Dillaman
2019-04-14 13:20         ` Stefano Garzarella
2019-04-14 13:20           ` Stefano Garzarella
2019-04-14 15:14           ` Jason Dillaman
2019-04-14 15:14             ` Jason Dillaman
2019-04-15  8:04             ` Kevin Wolf
2019-04-15  8:04               ` Kevin Wolf
2019-04-17  7:34               ` Stefano Garzarella
2019-04-17  7:34                 ` Stefano Garzarella
2019-04-17  8:04                 ` Kevin Wolf [this message]
2019-04-17  8:04                   ` Kevin Wolf
2019-04-19 12:23                   ` Stefano Garzarella
2019-04-19 12:23                     ` Stefano Garzarella
2019-04-23  7:56                     ` Kevin Wolf
2019-04-23  7:56                       ` Kevin Wolf
2019-04-23  8:26                       ` Stefano Garzarella
2019-04-23  8:26                         ` Stefano Garzarella
2019-04-23  8:38                         ` Kevin Wolf
2019-04-23  8:38                           ` Kevin Wolf
2019-04-29  9:58                           ` [Qemu-devel] [Qemu-block] " Kevin Wolf
2019-04-29  9:58                             ` Kevin Wolf
2019-04-29 10:11                             ` Stefano Garzarella
2019-04-29 10:11                               ` Stefano Garzarella
2019-04-29 10:25   ` [Qemu-devel] " Kevin Wolf
2019-04-29 10:25     ` Kevin Wolf
2019-04-29 14:04     ` Stefano Garzarella
2019-04-29 14:04       ` Stefano Garzarella
2019-04-29 14:30       ` Kevin Wolf
2019-04-29 14:30         ` Kevin Wolf
2019-04-29 15:55         ` Stefano Garzarella
2019-04-29 15:55           ` Stefano Garzarella

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=20190417080443.GA8330@localhost.localdomain \
    --to=kwolf@redhat.com \
    --cc=dillaman@redhat.com \
    --cc=jdurgin@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=sgarzare@redhat.com \
    /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).