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

[Fam Zheng <famz@redhat.com>]

On Tue, 10/25 16:57, Kevin Wolf wrote:
> 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.

Does this mean I should change ImageLockMode to:

 * exclusive
 * shared-write
 * shared-read
 * nolock
 * auto

Where "auto" maps to exclusive for O_RDWR and shared-read for O_RDONLY?

Fam