Patch to add support for advertising FULLSYNC to Mac OSX Clients

[Ralph Böhme]

On Fri, Apr 07, 2017 at 01:37:05PM -0700, Jeremy Allison wrote:
> 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.

Yup. But I bet the macOS SMB server implements this sync and if we implement it
async and send an interim response the client will explode.

Cheerio!
-slow