Patch to add support for advertising FULLSYNC to Mac OSX Clients

[Ralph Böhme]

Hi Kevin,

On Sat, Feb 18, 2017 at 06:32:00PM -0500, Kevin Anderson wrote:
> > > > I've also added code that ensures all prerequisite Samba options are
> > > > set on the fly when a Time Machine enabled share is connected.
> > > >
> > > > Now, secondly, the interesting part: have you ever tested if the TM
> > > > disk image filesystem survives network disconnects and/or hard server
> > > > power offs ?
> > > >
> > >
> > > I have been running the provided patch set for the past month and have not
> > > noticed any issues. In that time I have restarted the networking interfaces
> > > on the server I am using while backups are running without any issues being
> > > reported as well as being able to restore from the same backup. With that
> > > being said I have not tested a hard poweroff of the server as it is backed
> > > by an UPS. I will try to test this case and report back.
> >
> > did you run into any issues?
> >
> 
> So far I have not run in to any issues even doing a hard power off a
> couple of times.

ok.

> > > Also based one this email thread, Samba FLUSH operations are
> > > asynchronous by default:
> > >
> > > https://lists.samba.org/archive/samba/2008-September/143627.html
> >
> > yes, they are asynchronous *and* they're disabled by default (strict sync =
> > no), that's why we'ge going to enable it at runtime if fruit:time machine=yes.
> 
> OK.
> 
> >
> > > The asynchronous writes make me curious if this might be leading to
> > > some of the corruption edge cases as well as the case above.
> >
> > Hm, I guess the time window is small where we responsed to the flush request
> > while the fsync is still being done in a worker thread, but it's there, so yes,
> > this could be possible.
> >
> > > Is it possible to force a fsync() from the VFS layer? Could we add a handler
> > > for SMB2 FLUSH commands that check for a Reserved1 Field set to 0xFFFF and
> > > force an fsync()?
> >
> > Yes, we probably want to parse the Reserved1 field in the SMB2 frontend and pass
> > it down to the SMB2 flush request handler. Depending on the setting we could the
> > switch between callinc async flush() or sync.
> 
> OK. I will look to adding that to the provided patch but it may take
> some time as I understand some other parts of the code base. I think
> that would provide the necessary balance between data consistency and
> performance.

I can do this part, you can then do the testing. :)

Cheerio!
-slow