qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] Disk image shared and exclusive locks.


From: Kevin Wolf
Subject: Re: [Qemu-devel] [PATCH] Disk image shared and exclusive locks.
Date: Mon, 07 Dec 2009 12:51:59 +0100
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.4pre) Gecko/20091014 Fedora/3.0-2.8.b4.fc11 Thunderbird/3.0b4

Am 07.12.2009 12:28, schrieb Jamie Lokier:
> 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?

Sorry, I apparently misunderstood.  I was thinking about shared vs.
exclusive whereas you are talking about shared vs. none (vs. something
completely different). I think you're right there.

Kevin




reply via email to

[Prev in Thread] Current Thread [Next in Thread]