[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v8 00/36] block: Image locking series
From: |
Max Reitz |
Subject: |
Re: [Qemu-devel] [PATCH v8 00/36] block: Image locking series |
Date: |
Tue, 25 Oct 2016 15:30:43 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 |
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
- Re: [Qemu-devel] [PATCH v8 00/36] block: Image locking series, Max Reitz, 2016/10/21
- Re: [Qemu-devel] [PATCH v8 00/36] block: Image locking series, Kevin Wolf, 2016/10/24
- Re: [Qemu-devel] [PATCH v8 00/36] block: Image locking series, Max Reitz, 2016/10/24
- Re: [Qemu-devel] [PATCH v8 00/36] block: Image locking series, Kevin Wolf, 2016/10/25
- Re: [Qemu-devel] [PATCH v8 00/36] block: Image locking series,
Max Reitz <=
- Re: [Qemu-devel] [PATCH v8 00/36] block: Image locking series, Kevin Wolf, 2016/10/25
- Re: [Qemu-devel] [PATCH v8 00/36] block: Image locking series, Fam Zheng, 2016/10/26
- Re: [Qemu-devel] [PATCH v8 00/36] block: Image locking series, Max Reitz, 2016/10/26
- Re: [Qemu-devel] [PATCH v8 00/36] block: Image locking series, Kevin Wolf, 2016/10/26
- Re: [Qemu-devel] [PATCH v8 00/36] block: Image locking series, Max Reitz, 2016/10/26
- Re: [Qemu-devel] [PATCH v8 00/36] block: Image locking series, Fam Zheng, 2016/10/27
- Re: [Qemu-devel] [PATCH v8 00/36] block: Image locking series, Max Reitz, 2016/10/26
Re: [Qemu-devel] [PATCH v8 00/36] block: Image locking series, Fam Zheng, 2016/10/25