best strategy for preventing unnecessary oplock breaks on doublyopen files

[Steven French]

> Re: best strategy for preventing unnecessary oplock breaks on doublyopen
files
>
> On Wed, Oct 12, 2005 at 11:07:26AM +1000, tridge at samba.org wrote:
> > Jeremy,
> >
> >  > What about adding a reaquire oplock call into the UNIX extentions ?
> >
> > It might be better just to support the existing FSTCL ntiocl calls for
> > oplocks. These are supported by windows on local filesystems, but not
> > on remote filesystems. We can easily support them on remote
> > filesystems too. They are:
> >
> > #define FSCTL_REQUEST_OPLOCK_LEVEL_1 (FSCTL_FILESYSTEM | (0<<2))
> > #define FSCTL_REQUEST_OPLOCK_LEVEL_2 (FSCTL_FILESYSTEM | (1<<2))
> > #define FSCTL_REQUEST_BATCH_OPLOCK   (FSCTL_FILESYSTEM | (2<<2))
> >
> > w2k3 returns NT_STATUS_NOT_SUPPORTED on these, but at least their
> > existance on local filesystems means that the numbers are reserved,
> > and if windows ever does support this then its a pretty good bet they
> > will use these same opcodes.
>
> Ok, do we know what the data on the wire should look like ? The
> only reason for not doing so would be if we can't figure out what
> the actual bits should be (although it looks pretty simple - can't
> see that they need any really).
>
> Jeremy.

It would be even easier if for clients negotiating the future POSIX
extensions, we could ask that subsequent opens from the same client of an
open file on the same SMB session did not break oplock - I can manage cache
coherency on the client for two opens to the same file (at least for two
files of the same name - this is trickier for hardlinked files) - and
breaking oplock on two opens of the same file from the same client kills
performance.

The solution of fcntl reaquire oplock does not help AFAIK when both handles
stay open for a while and the other obvious solution (client maps all opens
on the same inode to one open handle) has a big performance killing problem
for a few apps - I e.g. worry about the case in which access patterns are
different for each of the two handles (one reading forward, one reading
backward or at the end of a file) - but if I collapse two opens onto one
over the wire - only local filesystems get to see the access pattern
properly so the server side can not do proper sequential access pattern
detection to aid in the dynamic tuning of the read-ahead algorithm.

I don't mind adding the fcntl reaquire oplock, but can only think of one
obvious time to use it ... when I have a multiply open file and have just
closed the next to last open instance.   Are you suggesting that I also
would use it as in the sequence (in the future):
      NTCreateX("foo",rw) req ->
      NTCreateX rsp   <-
      NTCreateX("foo,r) req ->
      oplock break <-
      oplock break response ->
      NTCreateX rsp <-
      FCNTL reaquire oplock ->
      FCNTL response <-
      (cached reads and writes)
      close
      close