Richard W.M. Jones wrote: > This is v3 of the lock patch, previously discussed here: > > http://lists.gnu.org/archive/html/qemu-devel/2009-12/threads.html#00461 > > In this version I've reverted back to the simpler interface. There is > now only one "lock" option, which can be lock=exclusive|shared|none. > > At Kevin Wolf's suggestion, > lock=exclusive|shared => all backing disks are locked shared > lock=none => no locks are acquired on any front or back disks
What do you recommend when backing disks are shared? > To keep the implementation very simple, the "commit" doesn't try to > acquire any extra locks. The "commit" command should probably never > be used when a backing file could be shared. Shared backing disks aren't safe after "commit" anyway. Other VMs may not be running at the time "commit" renders their image corrupt, so locks don't offer adequate protection against the backing disk being changed. One strategy that would offer a bit more protection would be: backing disks opened read-only, re-opened as writable at the time of "commit", and (where the format supports it) have a generation number stored in them which is incremented prior to the first write after writable open. The generation number would be stored in the referring delta image, which would complain if it found the backing file did not have a matching generation. This would at least alert the user to inconsistencies, and the exclusive lock arising from re-opening as writable would block "commit" if there were actively running VMs. A different strategy would be to simply have a user-settable flag in backing VM images meaning "shared therefore commit not allowed". You might think the user could do that by setting the permissions to read-only, but root ignores file permissions. (That's why we need a "ro" option too). -- Jamie
