On Mon, Dec 07, 2009 at 11:30:14AM +0000, Daniel P. Berrange wrote: > On Mon, Dec 07, 2009 at 11:19:54AM +0000, Jamie Lokier wrote: > > Daniel P. Berrange wrote: > > > > 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': > > > > No, the question is whether it makes sense to provide a 'shared' > > option on the command line, or simply to always map: > > > > image opened read only => F_FDLCK > > image opened writable => F_WRLCK > > > > and provide only a single command line option: 'lock'. > > That doesn't work in the case of setting up a clustered filesystem > shared between guests. That requires that the disk be opened writable, > but with a shared (F_RDLOCK) lock.
I think Jamie's point is that you might as well use no locking at all in this configuration. It's hard to see what lock=shared is protecting you against. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v
