Anthony Liguori wrote:
> I'm not sure whether it's best to enable it by default because, as I
> said earlier, I'm not comfortable with the lack of correctness wrt
> advisory vs. mandatory locking.
In my experience, disk images are accessed in one of five ways:
qemu-img
qemu
qemu-nbd
mount -o loop
cp/rsync
If all but the last implement qemu's advisory locking, that's comforting.
> Only qemu can implement this level of locking though so it's
> definitely something we ought to support.
That's not quite true. I have management scripts which call qemu-img
to determine the chain of backing images, and then can lock the chain.
(They determine the chain anyway, to provide reliable behaviour with
image names containing unusual characters and the old monitor, by
creating links with sane names in /tmp to the real files.)
But it's a lot nicer if qemu does it.
> However, from a UI and implementation perspective, I think we need
> significantly different semantics. You either want locking or you
> don't. I don't think the selection of none|shared|exclusive really
> makes sense.
Sometimes shared access to a raw image (partitioned or whole disk
filesystem) is ok, and sometimes it is not ok. Only the user knows
the difference, because only the user knows if the guests they are
running use distinct partitions in the same raw image, or cooperative
access to a shard image.
But does it make sense to request a shared lock in that case? Not
really. If you have a group of guests correctly sharing an image, you
still want to prevent running the same group a second time - and a
shared lock wouldn't do that, because each group would be requesting
shared locks.
So the distinction read/write makes more sense. Can anyone think of a
situation where a shared lock on an image opened for writing is useful?
-- Jamie
