Now an admin comes along with with libguestfs and attempts to access
the disk containing the GFS volume. libguestfs isn't part of the
cluster but that doesn't matter because you can happily access a GFS
filesystem in standalone mode provided it is not in use by any other
nodes.
We need to stop libguestfs opening the disk in exclusive-write mode
if other QEMU VMs are using it in shared-write mode.
I think it's simpler to use no locking in QEMU and let the cluster
management tool do the locking. The tool would be the one to invoke
QEMU, of course.
If QEMU with the shared-writable disks is been using F_RDLOCK, then
this would have prevent libguestfs opening the disk for write with
F_WRLOCK, since the F_RDLOCK blocks all F_WRLOCK attempts.
We really do have 3 combinations of locking / access mode here
- read-only + F_RDLOCK
- read-write + F_RDLOCK
- read-write + F_WRLOCK
So a single 'lock' flag is not sufficient, we need the shared/exclusive
semantics of the original patch.
I'd still prefer having a DWIM lock option that chooses the right kind
of locking depending on what you are doing.
You could have lock={no,yes,shared,exclusive} as follows
image type lock=no yes shared exclusive
raw, opened RO no F_RDLOCK F_RDLOCK F_WRLOCK
raw, opened RW no F_WRLOCK F_RDLOCK F_WRLOCK
qcow2, opened RO no F_RDLOCK F_RDLOCK F_WRLOCK
backing image no F_RDLOCK F_RDLOCK F_WRLOCK
qcow2, opened RW no F_WRLOCK error F_WRLOCK
backing image no F_RDLOCK error F_WRLOCK
However, I think lock=shared would be the wrong thing to do in the
cluster case. It's better if the management tool locks the partitions
for read-write instead, and this clearly does not belong in QEMU. It
would be a step in the wrong direction, and one that will be there
forever in QEMU.
I think only lock={no,yes} is the best option to start with.
Paolo
