Kevin Wolf wrote: > Am 07.12.2009 11:31, schrieb Jamie Lokier: > > 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? > > I think there are people using shared writable images with cluster file > systems.
Yes, they are. Please the following again: > > 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. If you run each guest in the disk-sharing cluster with 'lock=shared', it reflects that they are sharing - but that doesn't actually prevent mistakes, does it? If you run any of those guests a second time, it won't prevent that. So what's the point in the shared lock? Same when you have guests sharing a partitioned disk, with each guest accessing a different partition. E.g. a Windows/Linux dual boot, and you decide to run both guest OSes at the same time as they should be fine. You'd have to use 'lock=shared' - and when you do that, it doesn't protect you against running them again by accident. In all those cases you need locking at a higher level to be effective at stopping the wrong guests from being invoked simultaneously. So - can anyone think of a situation where being able to ask for a shared lock on an image opened for writing is useful? -- Jamie
