TimeMachine support for Big Sur - missing F_FULLFSYNC?

[Tom Talpey]

On 3/4/2021 9:44 AM, Andrew Walker wrote:
> 
> 
> On Thu, Mar 4, 2021 at 9:21 AM Tom Talpey via samba-technical 
> <samba-technical at lists.samba.org 
> <mailto:samba-technical at lists.samba.org>> wrote:
> 
>     Just a quick update to say that after an upgrade to Samba 4.11,
>     as expected Time Machine is working fine from Big Sur. It's
>     quite simple to configure, in fact - most everything flows
>     from minimal added settings in smb.conf:
> 
>        [global]
>          ...
>          vfs objects = fruit streams_xattr
> 
>        [TimeMachine]
>          ...
>          fruit:time machine = yes
> 
>     mDNS doesn't appear to be functioning for some reason, so
>     I've hotwired avahi-daemon to advertise the share.
> 
>     There are some quirks due to my use of a ZFS backend, and
>     the usual set of Ubuntu package mix-and-match differences,
>     which is why I'm only on 4.11 for now. I'm sorting out the
>     fruit:metadata, fruit:resource and fruit:nfs_aces options
>     relative to ZFS, but Time Machine appears to be not so
>     sensitive to these. One thing at a time.
> 
>     I'll try to add something useful to the wiki later.
> 
>     Tom.
> 
>     On 3/2/2021 8:14 AM, Tom Talpey via samba-technical wrote:
>      > On 3/2/2021 1:56 AM, Ralph Boehme wrote:
>      >> Hi Tom!
>      >>
>      >> Am 3/2/21 um 4:51 AM schrieb Tom Talpey via samba-technical:
>      >>> Does the 4.7.6 version of vfs_fruit support F_FULLFSYNC
>     advertisement?
>      >>> I find some mentions of earlier versions supporting F_FULLSYNC
>     (no extra
>      >>> "F"!), but zero mention of either fullsync or fullfsync in
>     release notes
>      >>> for any Samba/vfs_fruit version. Is that just a typo, in which
>     case, why
>      >>> is Big Sur complaining?
>      >>
>      >> You need at least 4.8 for this.
>      >
>      > Hi Ralph! I guess I figured Ubuntu would be off-by-one. :)
>      > I'll upgrade, had hoped to avoid a full network forklift but
>      > it's perhaps due.
>      >
>      > I think it would be good to refresh the wiki regarding this.
>      > I did find
>      >
>      >
>     https://wiki.samba.org/index.php/Configure_Samba_to_Work_Better_with_Mac_OS_X
>      >
>      > which does in fact state the 4.8 requirement in rather fine
>      > print, but the page says things like "here are suggestions"
>      > to "improve operability with Mac OS X", and "as far as I know".
>      > I'll see if I can help improve it after I muddle through the
>      > situation.
>      >
>      > Tom.
> 
> ZFS in general doesn't have an upper-limit on size of xattrs that can be 
> written, but Linux kernel puts cap at 64 KiB for max xattr size.
> ZFS on FreeBSD allows xattrs up to size_t bytes, but due to API 
> limitations (no pwrite for xattrs) you don't really want to go too 
> crazy. I once tried to write a 30 GiB alternate datastream to a samba 
> share on FreeBSD and was not satisfied with the result.
> Most of stuff written about NFSv4 ACLs on ZFS don't apply to general 
> Linux case (acltype is POSIX there).
> One ZFS dataset property that is particularly useful for Samba shares 
> performance-wise (for reading / writing xattrs) is xattr=sa. This 
> attribute is available in Linux, the FreeBSD port of zfs on linux, and 
> base FreeBSD IIRC in 13.

My datasets have the default xattr=on. If I change that to xattr=sa,
does that orphan the existing xattrs, I assume?

   https://github.com/openzfs/zfs/issues/443

Since I've only used the share for TM so far, it's not a huge big deal 
to wipe and redo, but it's not ideal. I'm not certain what important
stuff TM shoves into them, in any case. Maybe I'll give it a shot and
see what breaks!

Thanks for the idea, in any case.

Tom.