samba - Jul 2020 - Arstechnica reviews Samba-based iXsystems TrueNAS Core

Really nice write-up on the Samba-based
Open Source project !

https://arstechnica.com/gadgets/2020/07/an-easy-mode-for-zfs-we-test-the-truenas-core-12-0-beta/

Congratulations to the FreeNAS/TrueNAS folks !

Jeremy.

On Mon, Jul 20, 2020 at 7:47 PM Jeremy Allison via samba <
samba at lists.samba.org> wrote:
> Really nice write-up on the Samba-based
> Open Source project !
>
>
>
https://arstechnica.com/gadgets/2020/07/an-easy-mode-for-zfs-we-test-the-truenas-core-12-0-beta/
>
> Congratulations to the FreeNAS/TrueNAS folks !
>
> Jeremy.
>
> --
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba

Thank you Jeremy! Any feedback from the Samba community will be much
appreciated. Our samba port does differ from upstream FreeBSD and Samba
slightly. I'm working on cleaning up code and making it cross-platform
before opening upstream merge requests.

Some key areas of divergence:
A) libzfs related
1) shadow copies are provided by vfs_shadow_copy_zfs. This module has a few
benefits over shadow_copy2:
- support for absolutely arbitrary snapshot names. All snapshots will be
presented by default.
- libzfs is basically able to return the amount of space used by blocks
unique to a snapshot. This allows us to completely skip irrelevant
snapshots.
2) fsrvp support through vfs_zfs_fsrvp.
3) ZFS user / group quota support through vfs_ixnas (get/set nt quotas).
4) a time machine vfs module (vfs_tmprotect) that snapshots time machine
shares in the vfs disconnect function (and does some basic snapshot
maintenance). The goal is to give users a number of snapshots at clean
states in the history of a sparsebundle volume so that they can roll back
to a previous version of the time machine backup in case it gets corrupted.

I'm almost done with writing cross-platform (linux / freebsd) wrapper
around libzfs so that community members who want to use some of the nice
features of libzfs for writing their own VFS modules will have an easier,
and more documented / stable API for doing this.

B) FreeBSD related
1) vfs_ixnas uses native FreeBSD ACL APIs rather than passing through the
libsunacl shim layer. This means that we use fd-based calls
(acl_get_fd_np(), etc) where possible.
2) vfs_ixnas uses FreeBSD kernel DOS modes
3) (new in Beta / nightlies). We use a kqueue-based libtevent backend.
4) vfs_aio_fbsd uses libtevent / kqueue to perform POSIX AIO (using AIO
kevents) by submitting aio requests directly to libtevent. Early
indications from our performance team have indicated this strategy has paid
off in 12.0.

A few errata about GUI / websocket API:
1) We expose both Filesystem (NFSv4) and share ACLs. So use the correct API
or webui form for the task you want to complete :)
2) There's a known bug in the filesystem ACL editor in 12.0-BETA1. It
should work fine in our 11.3 and nightly branches.
3) User quotas can be managed through the GUI as well as through Samba (in
the GUI ZFS pool editor).

Another change compared to previous FreeNAS/TrueNAS versions is that
starting in 12.0 we default to using sa-based xattrs for "SMB"
datasets.
This yields a tremendous performance benefit for files that have a
relatively small number / size of xattrs (alternate data streams). Once the
bonus block is filled, ZFS will switch back to its normal xattr behavior.
This seems like a relatively beneficial compromise on speed without
sacrificing our ability to write large xattrs.

Once again, any feedback is much appreciated. If you decide to test and
encounter an issue, you can file a bug report on our bugtracker or just
email me directly.

Andrew

On Tue, Jul 21, 2020 at 06:25:02AM -0400, Andrew Walker wrote:
> Thank you Jeremy! Any feedback from the Samba community will be much
> appreciated. Our samba port does differ from upstream FreeBSD and Samba
> slightly. I'm working on cleaning up code and making it cross-platform
> before opening upstream merge requests.
> 
> B) FreeBSD related
> 1) vfs_ixnas uses native FreeBSD ACL APIs rather than passing through the
> libsunacl shim layer. This means that we use fd-based calls
> (acl_get_fd_np(), etc) where possible.
> 2) vfs_ixnas uses FreeBSD kernel DOS modes
> 3) (new in Beta / nightlies). We use a kqueue-based libtevent backend.
Oooh ! I want the above code in upstream/master please ! :-) :-).

I've been meaning to do that for a looong time, but never got
the spare capacity to get it done (sorry).
> 4) vfs_aio_fbsd uses libtevent / kqueue to perform POSIX AIO (using AIO
> kevents) by submitting aio requests directly to libtevent. Early
> indications from our performance team have indicated this strategy has paid
> off in 12.0.
Again, this sounds like a really interesting approach I'd love
to look at !

Thanks for the internal information, it's much appreciated.

Jeremy.