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

[Anthony Liguori <anthony@codemonkey.ws>]

Richard W.M. Jones wrote:
> Here's a second go at this patch.  The only change is that we add a
> second parameter (backinglock=none|shared|exclusive) which can be used
> to control locking on the first level (only) of backing disk.
>
> Dan Berrange convinced me there was a case to retain a distinct shared
> locking type.
>
> For any qemu instance which is going to use the "commit" command, I
> would advise using: lock=exclusive,backinglock=exclusive.
>
> For qemu instances which won't be using commit, I would advise:
> lock=exclusive,backinglock=shared.
>   

ETOOCOMPLEX

So the situation we're trying to support is:

1) something grabs exclusive (but why would it?)
2) we want to still be able to run things as shared

The alternative would be that we only provide lock=on|off.  For 
GPFS-like shared filesystems (:-P) we would always use lock=off.  It 
wouldn't protect us from a non-cluster aware writer.

I assume libguestfs is the user of exclusive.  However, wouldn't it be 
reasonable for libguestfs to want to be able to mount the GPFS volume 
and manipulate it?  Why wouldn't libguestfs want to also use lock=shared 
| lock=off in this case?

I think this is a knob you have to expose to your users.  I think that 
also means that shared/exclusive is not so useful.

Regards,

Anthony Liguori