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