Re: [Qemu-block] [PATCH v8 00/36] block: Image locking series

[Max Reitz]

On 25.10.2016 10:24, Kevin Wolf wrote:
> Am 24.10.2016 um 20:03 hat Max Reitz geschrieben:
>> On 24.10.2016 12:11, Kevin Wolf wrote:
>>
>> [...]
>>
>>> Now, the big question is how to translate this into file locking. This
>>> could become a little tricky. I had a few thoughts involving another
>>> lock on byte 2, but none of them actually worked out so far, because
>>> what we want is essentially a lock that can be shared by readers, that
>>> can also be shared by writers, but not by readers and writers at the
>>> same time.
>>
>> You can also share it between readers and writers, as long as everyone
>> can cope with volatile data.
> 
> Sorry, that was ambiguous. I meant a file-level lock rather than the
> high-level one. If we had a lock that can be shared by one or the other,
> but not both, then two locks would be enough to build what we really
> want.
> 
>> I agree that it's very similar to the proposed op blocker style, but I
>> can't really come up with a meaningful translation either.
>>
>> Maybe something like this (?): All readers who do not want the file to
>> be modified grab a shared lock on byte 1. All writers who can deal with
>> volatile data grab a shared lock on byte 2. Exclusive writers grab an
>> exclusive lock on byte 1 and 2. Readers who can cope with volatile data
>> get no lock at all.
>>
>> When opening, the first and second group would always have to test
>> whether there is a lock on the other byte, respectively. E.g. sharing
>> writers would first grab an exclusive lock on byte 1, then the shared
>> lock on byte 2 and then release the exclusive lock again.
>>
>> Would that work?
> 
> I'm afraid it wouldn't. If you start the sharing writer first and then
> the writer-blocking reader, the writer doesn't hold a lock on byte 1 any
> more,

But it holds a lock on byte 2.

>       so the reader can start even though someone is writing to the
> image.

It can't because it would try to grab an exclusive lock on byte 2 before
grabbing the shared lock on byte 1.

Max

>        On the other hand, the writer can't keep an exclusive lock
> because it would block other users that can share the image.
> 
> Kevin
>

signature.asc
Description: OpenPGP digital signature