best strategy for preventing unnecessary oplock breaks on doublyopen files

[Jeremy Allison]

On Wed, Oct 12, 2005 at 02:39:49PM -0500, Steven French wrote:
> 
> 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 change in state logic to do that would be quite hard on
the server side. Essentially you're asking for multiple exclusive
oplocks to be active. I can't imagine the number of asserts and
logic checks we have in currently to prevent that :-).

> 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

Yep - that looks about right to me.

Jeremy.