Re: [Qemu-devel] [PATCH] Disk image shared and exclusive locks.

["Daniel P. Berrange" <berrange@redhat.com>]

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 :|