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