On Mon, Dec 07, 2009 at 11:49:32AM +0000, Daniel P. Berrange wrote: > On Mon, Dec 07, 2009 at 11:31:47AM +0000, Richard W.M. Jones wrote: > > 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: > > > > > > > > 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. > > This is saying that there is no need to protect 'shared writers' > from 'exclusive writers', which is not true. [example snipped]
OK so the case for lock=shared is where you have a shared clustered resource, *and* an uber-admin-tool which may require exclusive access to the resource. I now understand, and that seems to make sense (albeit a rather rare case). It has to be said the only reason I implemented the shared mode in the original patch, was because both POSIX and Win32 (LockFileEx) have the distinction between shared and exclusive, in other words 'coz it was easy :-) Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/
