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

[Kevin Wolf <kwolf@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 3234 bytes --]

Am 25.10.2016 um 15:30 hat Max Reitz geschrieben:
> 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.

Apparently I failed to understand the most important part of the
proposal. :-)

So we have two locks. Both are only held for a longer time in shared
mode. Exclusive mode is only used for testing whether the lock is being
held and is immediately given up again.

The meaning of holding a shared lock is:

    byte 1: I can't allow other processes to write to the image
    byte 2: I am writing to the image

The four cases that we have involve:

* shared writer: Take shared lock on byte 2. Test whether byte 1 is
  locked using an exclusive lock, and fail if so.

* exclusive writer: Take shared lock on byte 2. Test whether byte 1 is
  locked using an exclusive lock, and fail if so. Then take shared lock
  on byte 1. I suppose this is racy, but we can probably tolerate that.

* reader that can tolerate writers: Don't do anything

* reader that can't tolerate writers: Take shared lock on byte 1. Test
  whether byte 2 is locked, and fail if so.

Seems to work if I got that right.

Kevin

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]