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
