Am 23.04.2019 um 10:38 hat Kevin Wolf geschrieben: > Am 23.04.2019 um 10:26 hat Stefano Garzarella geschrieben: > > 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? > > I think so, yes.
Hm, this is an RFC patch, which suggests that it wasn't originally meant to be merged as it is. Are you going to send a new version, or did it turn out to be exactly what we want and the "RFC" tag was a mistake? Kevin