Giving a VFS a chance to be told that an oplock break is occurring

[Jeremy Allison]

On Wed, Mar 28, 2012 at 05:02:41PM -0700, Richard Sharpe wrote:
> On 3/28/12, Jeremy Allison <jra at samba.org> wrote:
> > On Wed, Mar 28, 2012 at 08:35:56PM +0200, Volker Lendecke wrote:
> >> On Tue, Mar 27, 2012 at 07:51:09PM -0700, Richard Sharpe wrote:
> >> > > Definitely widen out to samba-technical... I'm CC:ing vl on the
> >> > > reply for his thoughts, I know he's spent more time thinking about
> >> > > async issues in the VFS than I have.
> >> >
> >> > If you are doing read-ahead or write-behind in a VFS module and an
> >> > oplock break occurs then you need to know about it, it seems to me,
> >> > either to invalidate or flush ...
> >>
> >> With the current oplock architecture, isn't it possible also
> >> messaging_register for a MSG_SMB_BREAK_REQUEST with a
> >> different handler? This way you will get the Samba-internal
> >> oplock breaks. You could also very cheaply compare
> >> fsp->oplock_type with a value cached locally in your module.
> >> If that changes, a break has happened.
> >
> > Oooh. Good catch - yes that's true.
> 
> Do we get told when the break is happening or after the fact?
> 
> After the fact is OK for read caching but not for write(-behind) caching.
> 
> Imagine we have write(-behind) cached data. An oplock break arrives
> and the client is told to break back to something lower than
> exclusive, but it has no data.
> 
> However, if the VFS is also not told then and only discoveres it later
> when an operation arrives, then we might have lost writes ...

The holder of the oplock gets the MSG_SMB_BREAK_REQUEST message
when someone else requests an open that would break - i.e. the
receiver of this message is the process that should do the
break. You can register multiple handlers to receive the message
so long as the private pointer is different for each - that
allows multiple stacked modules to register.

However you don't get to select the order in which the
handlers are run, so if you require synchronous operation
that might be a problem.

Jeremy.