Patch to add support for advertising FULLSYNC to Mac OSX Clients

[Kevin Anderson]

Hi everyone,
   So I am in the middle of testing the latest patch that Ralph sent
out. So far the patch seems to be working as expected (except for
setting fruit:aapl globally and nothing else appears to break the
server, I am looking in to this though) but wanted to throw a few
comments in here in case it helps any. If it doesn't feel free to say
so as well. :)

Just a rough background on the time machine backup format as I
understand it: It is a sparse disk bundle which gets mounted by the
client, formatted as HFS+, then used as a backup destination.


>> > > 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.

>From what I can tell through tracing fsync's on the server and traffic
from the client, the client writes data to a band asynchronously and
the final write to a band triggers the fsync (or after a set amount of
data is added to the band) at which point the client waits on a reply
from the server before attempting to move on to the next band in the
image or perform another operation.

>
> 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.

I understand that you stated it *can* kill performance rather than it
will but I wanted to add that not every flush generates a sync. In the
last backup set that I ran, 1500 FLUSH requests were sent and of those
requests, only 76 sync flushes were sent. I am not sure if that helps
at all but I can try to quantify impact more if necessary.