Message ID | 20110114162104.GB19184@lst.de |
---|---|
State | New |
Headers | show |
* Christoph Hellwig <hch@lst.de> [2011-01-14 10:27]: > Add a new size_changed flag in the BlockDriverState and call the > change_cb callback to notify drivers about a size change. > > Signed-off-by: Christoph Hellwig <hch@lst.de> > > Index: qemu/block.c > =================================================================== > --- qemu.orig/block.c 2011-01-14 17:05:49.527003363 +0100 > +++ qemu/block.c 2011-01-14 17:07:23.206255143 +0100 > @@ -1135,6 +1135,10 @@ int bdrv_truncate(BlockDriverState *bs, > ret = drv->bdrv_truncate(bs, offset); > if (ret == 0) { > ret = refresh_total_sectors(bs, offset >> BDRV_SECTOR_BITS); > + if (bs->change_cb) { > + bs->size_changed = 1; > + bs->change_cb(bs->change_opaque); > + } Do we want to check to ensure the size_changed flag isn't set before doing a second resize event? I'm wondering if the truncate takes $longtime and user gets impatient and issues a second resize command. How should we respond? Ignore it? queue it up? Is there any other path that invokes bdrv_truncate? If so, do we want invoke the call back in those scenarios or only if the truncate is initiated from the monitor invocation? > } > return ret; > } > Index: qemu/block_int.h > =================================================================== > --- qemu.orig/block_int.h 2011-01-14 17:05:49.537004411 +0100 > +++ qemu/block_int.h 2011-01-14 17:06:02.539004271 +0100 > @@ -167,6 +167,7 @@ struct BlockDriverState { > char backing_format[16]; /* if non-zero and backing_file exists */ > int is_temporary; > int media_changed; > + int size_changed; > > BlockDriverState *backing_hd; > BlockDriverState *file;
> Do we want to check to ensure the size_changed flag isn't set before > doing a second resize event? I'm wondering if the truncate takes > $longtime and user gets impatient and issues a second resize command. > How should we respond? Ignore it? queue it up? The truncate is synchronous and the monitor command won't return before it's done. The interfact might be a bit cleaner if we'd just pass the reason for the change callback as another argument. I'll do that for the next respin. > Is there any other path that invokes bdrv_truncate? If so, do we want > invoke the call back in those scenarios or only if the truncate is > initiated from the monitor invocation? Currently only the qemu-img and qemu-io tools invooke bdrv_truncate. But if we grow new users we should always tell the driver/guest about it so that it knows about the size change.
Index: qemu/block.c =================================================================== --- qemu.orig/block.c 2011-01-14 17:05:49.527003363 +0100 +++ qemu/block.c 2011-01-14 17:07:23.206255143 +0100 @@ -1135,6 +1135,10 @@ int bdrv_truncate(BlockDriverState *bs, ret = drv->bdrv_truncate(bs, offset); if (ret == 0) { ret = refresh_total_sectors(bs, offset >> BDRV_SECTOR_BITS); + if (bs->change_cb) { + bs->size_changed = 1; + bs->change_cb(bs->change_opaque); + } } return ret; } Index: qemu/block_int.h =================================================================== --- qemu.orig/block_int.h 2011-01-14 17:05:49.537004411 +0100 +++ qemu/block_int.h 2011-01-14 17:06:02.539004271 +0100 @@ -167,6 +167,7 @@ struct BlockDriverState { char backing_format[16]; /* if non-zero and backing_file exists */ int is_temporary; int media_changed; + int size_changed; BlockDriverState *backing_hd; BlockDriverState *file;
Add a new size_changed flag in the BlockDriverState and call the change_cb callback to notify drivers about a size change. Signed-off-by: Christoph Hellwig <hch@lst.de>