Samba 3.0.32 - oplock code

itay dar itay.dar at gmail.com
Fri Dec 12 20:35:41 GMT 2008


On Fri, Dec 12, 2008 at 3:35 PM, Volker Lendecke
<Volker.Lendecke at sernet.de>wrote:

> On Thu, Dec 11, 2008 at 11:26:32AM -0800, Jeremy Allison wrote:
> > > I was thinking on just marking the breaker entry as downgrade one and
> > > than sending a notify to all.
> > > And checking In open code path if this is a downgraded one, I am
> testing
> > > this change and it seems to work (but I had to touch lot of files)
> > > I am giving it a bit more qa time before posting.
> >
> > That's quite a change. I'm not sure I'd be happy with
> > that. I hate new flags/states inside the share mode
> > code, we already have too many for people to understand.
>
> That's true, but the alternative would be to hold the lock
> for much longer. I don't know I like that idea either.
>
> > > An alternative was to break to the client (or just remove the fake
> > > oplock ) under the lock and than send notify to everyone else, this
> will
> > > do the same trick.
> >
> > This sounds simpler to me, but I need to understand the
> > logic completely before I'll say "ok" on that one.
> >
> > You've obviously been thinking about this for a long time,
> > I'll have to context switch all this back into my head before
> > I comment fully :-).
>
> Same here.
>
> Itay, could you do at me (and probably others) a favor and
> describe that last "simpler" proposal in the context of the
> problem again? To me this is tricky stuff, and I want to
> make sure I get the right context chain from the mail
> thread, I don't want to risk being confused here :-)
>
> Thanks,
>
> Volker
>

Yes, both my posting are correlated so i will explain them both.

In delay_for_oplocks can grant level two oplock when in fact it  shouldn't.
in order to grant a share level two oplock, all others holders must be
either level two oplock or fake level two oplock, this is in order that on
case of a write or a lock request they will have to send an async break, if
not a corruption of state might occur where a client reads stale data.

i will try to look on the samba torture test to see if i can reproduce this
state in it, the patch i proposed should solve this issue.

So a client that views a file and sees all entries having a level two oplock
(fake or not) should get a level two oplock fake or real depending on his
request.

now when a client decides to break all level2 oplocks he send everyone an
aync oplock break under the tdb lock (including to himself) then he frees
the tdb lock.
lets say some open request waited on that tdb lock, the request cant know a
downgrade had happend so it will get a level two oplock, but no other owner
will notify it on changes.

This is solved basicly by changing the share entry data under the tdb lock,
before or after sending the oplock break requests. (the tdb lock is what
counts)

here there are 3 options :
1. have a new state and keep the reguler flow the same (sending the async
oplock to breaker client as an async event)

2. send the client the oplock break request from the release function and
update the share entry database.

3. send the client a break and update all other share entries also.

Number one is my orignal suggestion, but number two seems as the best
solution possible.

i will try to look into the code of the samba tourte suit and see if i can
ehance it.

many thanks,

itay dar


More information about the samba-technical mailing list