The magic of ZFS and NFS (2nd try)

[Rainer Duffner]

> Am 21.02.2015 um 19:23 schrieb Jordan Hubbard <jkh at ixsystems.com>:
> 
> 
>> On Feb 21, 2015, at 9:36 AM, Christian Baer <christian.baer at uni-dortmund.de> wrote:
>> 
>> But why shouldn't I use /etc/exports? I have read people writing this (don't 
>> use /etc/exports) in forums when searching for answers, however the current 
>> manpage for zfs says this:
> 
> FreeNAS has more experience with sharing things from ZFS than anyone else in the BSD community (that’s not hyperbole, it’s simply fact).  We don’t use any of the zfs sharing flags.  Those were intended more for Solaris (sharesmb, for example - FreeBSD lets you do that, but what does it *mean* when you don’t have a native CIFS service?).   FreeBSD has never integrated ZFS’s notion of sharing or, for that matter, a number of other things like drive hot sparing and automatic replacement, and you’re seeing the results of ZFS’s solaris roots still not lining up 100% with their new FreeBSD home.  That’s all.
> 
> I would simplify things, just as FreeNAS has (for good reasons), and simply have ZFS be “a filesystem” from FreeBSD’s perspective and share it just as you would UFS.



Interesting.

I admit I don’t use NFS v4.
Is it much faster than NFS v3 these days?

But I’ve always added the line from exports(5) into the sharenfs property like

zfs get sharenfs datapool/nfs/ds3-documents
NAME                        PROPERTY  VALUE                                                       SOURCE
datapool/nfs/ds3-documents  sharenfs   -maproot=1003 -network 10.10.10.0 -mask 255.255.255.0  inherited from datapool/nfs

These lines get written into /etc/zfs/exports

I like it that way because if a filesystem is destroyed, I don’t have to remember removing it from /etc/exports.

I also admit I’m heavily influenced by Solaris on this particular setting…