Am 16.05.2016 um 08:33 hat zhangzhiming geschrieben: > hi, i read some source code by your tips, and i have some conclusions: > > 1. Old version of QCOW2 image does not store the total size of snapshot, so, > we > can’t > add the function to the old version of QEMU, and the function of QCOW2 > resize with snapshots > will be limited in V3 image or it will make confusion. so that is right. > 2. I read the source code of bdrv_truncate from master, and the function > “bdrv_dirty_bitmap_truncate" have done this, so > it means that i need not to consider the resize of bitmap while resize > QCOW2 ?
This is correct, qcow2_truncate() does not need to consider it. However, snapshot loading must consider it. Essentially, when allowing snapshots with different image sizes, qcow2_snapshot_goto() is an implicit resize as well, even though it doesn't go through bdrv_truncate(). > 3. there is a function named “qmp_marshal_block_resize”, > this function will block IO requests when resizing a image, and it seems > that it called callback function to notify the > guest, and we don’t need to set BLOCK_OP_TYPE_RESIZE blockers. is it > correct ? I think you mean qmp_block_resize(). (This is the function that is called by the automatically generated qmp_marshal_block_resize().) For the same reason as above (snapshot loading = implicit resize), we need to check the blocker and call the callbacks for snapshot loading now. Kevin > On May 7, 2016, at 11:13 AM, zhangzhiming <zhangzhimin...@meituan.com> > wrote: > > sorry, i forgot to cc qemu-bl...@nongnu.org. > > zhangzhiming > zhangzhimin...@meituan.com > > > > > On May 7, 2016, at 10:47 AM, zhangzhiming <zhangzhimin...@meituan.com> > wrote: > > thank you for your reply, and i am glad to join to the development of > qemu. > i will try my best to finish this new function. > > have a good day! > > zhangzhiming > zhangzhimin...@meituan.com > > > > > On May 3, 2016, at 4:44 PM, Kevin Wolf <kw...@redhat.com> wrote: > > [ Cc: qemu-block ] > > Am 29.04.2016 um 10:59 hat zhangzm geschrieben: > > hi, i want to implement the function of qcow2 resize which has > snapshots. > > each snapshot of qcow2 will have a separate total size, and > when apply > a snapshot, the image can be shrunk, and the total size of > image will > change after apply to a snapshot with different size. > > now, there is a disk_size value in struct QcowSnapshot, i only > need to > change the size of current active image layer when apply a > snapshot > with different size, and the io request will be limit in the > range of > active layer. > > > Yes, I think today the qcow2 format provides everything that is > needed > to implement this. You need to make sure that we have a v3 image > so > that > the virtual disk size is actually stored in the snapshot (this > field did > not exist in v2 images yet). > > What you need to consider is that loading a snapshot becomes > similar to > resizing an image then and you need to do the same things for it. > For > example, we need to figure out what to do with associated dirty > bitmaps > (adapt them to the new size like in bdrv_truncate()?), call resize > callbacks so that the guest devices actually see the changes size > and > possibly also consider the BLOCK_OP_TYPE_RESIZE blockers to > prevent > a > size change while the image is in use. > > > and i want my code merged into the master of qemu. > > > The wiki has a few tips on how to submit patches for qemu: > http://wiki.qemu.org/Contribute/SubmitAPatch > > For a patch (or patch series) like this, you will want to CC at > least > qemu-block and qemu-devel, plus possibly a few individual people. > > Kevin > > > > > > > >