Re: [Qemu-devel] [PATCH RFC 1/1] block/rbd: increase dynamically the image size

[Stefano Garzarella <sgarzare@redhat.com>]

On Tue, Apr 23, 2019 at 09:56:19AM +0200, Kevin Wolf wrote:
> Am 19.04.2019 um 14:23 hat Stefano Garzarella geschrieben:
> > Hi Kevin,
> > 
> > On Wed, Apr 17, 2019 at 10:04:43AM +0200, Kevin Wolf wrote:
> > > 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.
> > 
> > Very interesting, I'll try to add this support also in the rbd driver.
> 
> I don't understand - what is the thing you want to add to the rbd driver?
> qcow2 doesn't need special protocol driver support for doing this, and I
> don't think the QEMU rbd driver has any metadata that could be split off.
> 

Oh sorry, I didn't understand that was completely independent from the
protocol.

> > > > > 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
> > 
> > I did some tests and it seems that the cost of rbd_resize() is
> > negligible. IIUC it only updates the metadata without allocating any
> > blocks (if we are growing, like that case).
> > 
> > Anyway the automatic resize will not affect the current use-case (raw
> > images on rbd), where the file size is set during the creation, so I
> > think there should not be side effects with this patch.
> 
> Okay, sounds good.
> 
> > I'm also adding the support for preallocation (i.e. full) in the rbd
> > driver that can be useful for qcow2 images.
> > 
> > If you prefer I can resend this patch with the preallocation series.
> 
> Let's keep seperate things separate. Huge patch series are always harder
> to handle.

Okay, thanks for the suggestion!

Should this patch go through your tree?

Thanks,
Stefano