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'.
-- Jamie
