Il 02/03/2012 14:00, Kevin Wolf ha scritto: > Am 01.03.2012 17:52, schrieb Paolo Bonzini: >>>> But you can even keep from your first patch the drive-reopen command and >>>> not make it atomic, that shouldn't be a problem. >>> >>> I'm not sure whether it makes sense for a separate drive-reopen or >>> whether to just add this to blockdev-transaction (or even both); I can >>> make libvirt use whichever color bikeshed we pick. There's definitely a >>> transaction aspect here >> >> It's not so much atomicity, it's just safety. The drive-reopen command >> must be implemented in a similar way to bdrv_append; it must not do a >> close+reopen in the same way as the existing blockdev-snapshot-sync >> command, but that's just that blockdev-snapshot-sync was implemented >> poorly. > > For reopen this is a bit harder because you deal with already opened > images and you must never have the same image opened twice at the same time.
This is only for read-write images, and the backing files are read-only, so this shouldn't be a problem, no? Hmm, actually there could one problem. Say you switch from base->old to base->new; if old is the outcome of a live snapshot operation, base will still be open read-write. So perhaps we do need a new method like bdrv_freeze; after bdrv_freeze you know that bdrv_close will not need to write to disk. So e.g. for QED bdrv_freeze will turn off the need-check bit. Paolo