Patch to add support for advertising FULLSYNC to Mac OSX Clients

[Ralph Böhme]

Hi Kevin,

On Wed, Jul 05, 2017 at 08:57:09PM -0400, Kevin Anderson wrote:
> > attached is a patch (on top of a current TM patchset) which forces every SMB2
> > FLUSH request to take at least 1 ms which will trigger an request-went-async
> > SMB2 response to the client.
> > 
> > Can you please test this with a macOS client? Please check whether the patch
> > really produced async resonses for the SMB2 FLUSHes.
> >
> 
> Was the intent of this patch just to see if an async response would cause an
> error on the client?

yup.

> If so it appears the TimeMachine client does the right thing and handles the
> errors appropriately along with the async smb flush.

Ah, good.

> I applied the patch with 2 changes. Those changes were changing msleep to smb_msleep
> (patch was missing an include or smb_msleep is what was intented) and changing volume_caps
> to caps in config-time_machine since they didn't match the variable on master.

Oh, sorry! :/ Looks like I didn't start a build with the hackish patch.

> Ultimately with the patch applied it took a significant amount of time for a backup which I
> assume was intended.

Well, the intention was not to slow it down, but just to see if it copes with
the async response.

> I saved a PCAP and can send that if you have a preferred method.

Can you just put it somewhere where I can download it from?

> Based on my interpretation, I see a flush request from the client sent as a
> sync command, a response from the server with a STATUS_PENDING error message
> with the async bit set, and finally an async flush response is sent to the
> client.

Good. That's how it's supposed to work.

> I also looked again at my home server with my previous patch applied (without the smb_msleep call)
> and I see a similar async command and response as what I stated above for some of the flush
> responses which has been working without any issues. I think the reason I didn't notice
> it before was because I was doing the packet capture analysis against a machine with an SSD
> rather than a spinning disk which allowed the flush requests to complete without going async.

I guess that means we're good to go. I'll send a final patchset to the mailing
list next week.

Cheerio!
-slow