Patch to add support for advertising FULLSYNC to Mac OSX Clients

[Kevin Anderson]

Hi Ralph,
   I started an attempt to implement the remaining piece of this patch
and I have parsed out the reserved1 field in the
smbd_smb2_request_process_flush function. Does that seem appropriate
to you? If so, I only have to determine the best way to pass the fsync
to the actual file. Can/should the fsync be handled in the fruit
module? I would be open to any advice that you have as I have tried a
number of things already but they were unsuccessful.

I have attached a patch (with some extra print statements for my own
use. They will be removed before the final patch is submitted) that
parses the field.

Thanks,
Kevin

On Tue, Feb 21, 2017 at 4:06 PM, Kevin Anderson <andersonkw2 at gmail.com> wrote:
> Hi Ralph,
>
> That works for me. :) Let me know if there is anything else I can help with.
>
> -Kevin
>
> On Tue, Feb 21, 2017 at 12:31 PM, Ralph Böhme <slow at samba.org> wrote:
>> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: parse-reserved1-flush.patch
Type: text/x-patch
Size: 1555 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20170402/25d403e1/parse-reserved1-flush.bin>