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

[Volker Lendecke]

On Wed, Mar 28, 2012 at 08:12:24PM -0700, Jeremy Allison wrote:
> On Wed, Mar 28, 2012 at 06:12:10PM -0700, Richard Sharpe wrote:
> > >
> > > 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.
> > 
> > OK, that is great. I don't (think I) care what order they are
> > delivered in, just as long as they are delivered before the other
> > party opening the file get the go ahead to read/write the file.
> 
> You can probably count on that, but it's a bit of a hack.
> 
> If the open oplock handler gets called first, it sends
> the break request to the client then returns. At that point
> your handler is guarenteed to run before the reply from the
> client is received.
> 
> Problem is that's dependent on the current code. If you
> rely on these semantics later changes may break that promise.

Also, you don't see the kernel oplock breaks. Before we put
a corresponding operation into the VFS we need to think
about leases as well and how they fit. Also, we are right
now looking more closely at the kernel oplock interface,
which seems to not fit Samba's needs very closely. So, if
possible, it would be great if we could get a few months
before deciding upon such an operation. Alternatively, if
you could live with it changing significantly soon, we can
certainly put one in now.

Volker

-- 
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9
AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
http://www.sernet.de, mailto:kontakt at sernet.de