Patch to add support for advertising FULLSYNC to Mac OSX Clients

[Jeremy Allison]

On Fri, Apr 07, 2017 at 10:22:58PM +0200, Ralph Böhme wrote:
> On Fri, Apr 07, 2017 at 01:20:55PM -0700, Jeremy Allison wrote:
> > On Fri, Apr 07, 2017 at 10:13:25PM +0200, Ralph Böhme wrote:
> > > On Fri, Apr 07, 2017 at 11:04:04AM -0700, Jeremy Allison wrote:
> > > > 
> > > > Doesn't this need to be SMB_VFS_FSYNC_SEND() and
> > > > the whole thing use the standard async callback
> > > > mechanisms ?
> > > > 
> > > > Looking at https://goo.gl/Lw5bdz it doesn't say we can't
> > > > return an intermediate response followed by a completed
> > > > response.
> > > 
> > > It says:
> > > 
> > >   In response, the server must first process the SMB2 FLUSH command in the usual
> > >   manner, and then must flush the data to stable storage (that is, flush the
> > >   physical disk’s track cache) before responding to the client.
> > >   
> > > So we must use the sync sync.
> > 
> > It says:
> > 
> > "In response, the server must first process the SMB2 FLUSH command in the usual manner"
> > 
> > which for us is to go async if it takes longer than our normal
> > return time. Can we check with Apple. This is ambiguous, as I can't
> > believe their client will fail this if a server goes async. I
> > very much doubt the client code is special-cased for this to
> > fail if a server goes async. They are just waiting for the
> > final response.
> 
> My bet is that their server won't go async. We can ask them.

Yeah, but that is a server implementation detail.

> > We should ask for a clarification to:
> > 
> > "flush the physical disk’s track cache) before making a final
> > response to the client".
> 
> There's no mention of *final* response in the doc. It just says
> 
>   before responding to the client.
> 
> I'm reading this as "sync and don't cheat!".

But making that single call forced-sync makes no sense.

Enforcing that client side would mean adding extra code
to prevent any other pending non-related SMB2 requests
from being processed whilst this code is awaiting response.

I really looks like an ambiguous document statement than
anything like a design decision.

I really don't want us to force sync on this until I know
this is really mandatory in the spec, and even then I
want the spec ammended to say so :-).

Allowing clients to force sync like this can *kill* any
asyncio performance from us.