TimeMachine support for Big Sur - missing F_FULLFSYNC?

[Andrew Walker]

On Thu, Mar 4, 2021 at 10:05 AM Tom Talpey <tom at talpey.com> wrote:

> 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
>
> No. It shouldn't orphan any xattrs. Xattrs will be preferentially stored
as SA, but both SA-based and file-based xattrs will be returned in the
xattr list. Having it enabled from the get-go ensures that samba's
DOSATTRIB and NTACL xattrs get written to the "fast" place.

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!


>
Since this is only a time machine share for now, I wouldn't worry too much.
Slower xattr list / read performance is more of an issue when you have
normal file share.