> 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.
