On Mon, Dec 07, 2009 at 10:31:28AM +0000, Jamie Lokier wrote:
> 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?
Isn't this what Richard has already done ? The patch implements 'shared'
as a 'F_RDLCK' lock and 'exclusive' as 'F_WRLCK':
+ if (bdrv_flags & BDRV_O_LOCK_SHARED)
+ lk.l_type = F_RDLCK;
+ else /* bdrv_flags & BDRV_O_LOCK_EXCLUSIVE */
+ lk.l_type = F_WRLCK;
It seems we're just debating different terminology for the same thing.
Indeed the fcntl() man page uses read/write and shared/exclusive
interchangably too
The l_type field can be used to place a read
(F_RDLCK) or a write (F_WRLCK) lock on a file. Any
number of processes may hold a read lock (shared
lock) on a file region, but only one process may hold
a write lock (exclusive lock). An exclusive lock
excludes all other locks, both shared and exclusive.
Regards,
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|
