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