[LU-8379] Possible badness with VBR and lock replay

Fri, 8 Jul 2016 17:36:53 +0000

As part of working on ~~LU-8347~~, Jinshan raises some valid points I think.

Let's say we have a VBR enabled system, recovery completed, but a client failed to join that had outstanding write locks and some dirty data.

Now before this client rejoins, another client reads some data from a file that was modified (but not yet replayed) but this first client.

questions:
1. when the first client reconnect, would it be accepted (file version is not changed because there were no writes, so I think YES?)
2. when it is accepted - that means second client actually accessed stale data - this is bad, right?
3. As part of read second client also obtained some read locks on the data that client one is going to change - this is not good.
4. What happens with replayed locks from client 1 in presence of already granted conflicted write locks?
5. In fact if somebody has a write lock on a file - that does not change file version yet, right? Only writes do - so what's to prevent conflicting writes to be in flight for such files?

I am capturing this here to better understand all these scenarios before categorizing this with a priority accordingly.

Whamcloud Community JIRA

[LU-8379] Possible badness with VBR and lock replay