ZFS + NFS + multiple hosts/mount options ..?

[Willem Jan Withagen]

On 31-8-2016 18:51, Brandon J. Wandersee wrote:
> 
> Willem Jan Withagen writes:
> 
>>>  There is one BIG problem: deep ZFS hierarchies. If I need to export 100
>>> FSes (100 users' home directories, for example) in one ZFS tree to 4
>>> networks (2xIPv4, 2xIPv6) I need to add 400 (!!!) lines to /etc/exports
>>> by hands. All these lines will be virtually the same, and good luck to
>>> maintain this mess.
>>>
>>>  If "sharenfs" supports multiple hosts/networks, I need to set this
>>> property ONCE (on zpool/home, parent of all FSes in question) and IT'S
>>> ALL! And if I need to change same options, I need to change it ONCE and
>>> re-export ZFS.
>>>
>>>  Unfortunately, it is NOT enough to export parent FS :(
>>
>> Hi Lev,
>>
>> I agree with you
>>
>> More or less the arguments I had at that time.
>> (though I don't have that many FSes.)
>>
>> And I gave up. Perhaps that tells more about me than anything else.
>> The discussion I tried to have was cut short with the argument that it
>> would not go in because  upstream would not like it, or would not want
>> in the version I submitted.
>>
>> But please do feel free and get something in that would please more.
> 
> Has a script that recurses through a directory tree and adds valid
> entries to the exports file been considered as a viable option?
> "sharenfs=" just adds syntactically valid entries to /etc/zfs/exports;
> NFS does the rest.
> 
> There are probably a number of reasons that making "sharenfs" more
> complicated isn't in the cards. I suspect "upstream won't like it" may
> just be short-hand for "Nobody wants to do the work to implement and
> maintain a feature across multiple operating systems that can be
> implemented by the tiny fraction of users who want it with the tools
> already available to them." But besides that, yes, being able to set an
> option once at a root point and have that option affect all descendant
> filesystems appears simple and easy, because you're dealing with one
> very simple use case with predictable results. That simplicity and
> predictability immediately break down once you start changing options
> for individual descendant filesystems, which someone would inevitably
> want to do. ("If it's possible to implement this, then why not that?
> That's simple enough, right?") Or what about people who only want to
> export 60 of the 100 child filesystems? They still have to either set
> the property manually on all their filesystems, or create new dataset
> trees to separate shared from unshared filesystems. Is implementing
> inheritance for "sharenfs" really going to relieve enough tedium of
> enough users to make it worthwhile? And then there's the fact that NFS
> by its nature does not cross filesystem boundaries, which ZFS
> inheritance would do if the "sharenfs" property were inherited, making
> ZFS sharing unpredictable to someone used to managing complicated NFS
> groups on anything other than ZFS. At that point it's become easier to
> manage lots of shares and harder to manage only a few shares
> exclusively. In such cases, is it really easier *not* to write an
> exports file by hand? That's what you're getting, after all: whether you
> copy lines in a text file or enter `zfs set sharenfs=` 50 times, you're
> still typing out the name of filesystem 50 times while everything else
> is automated...
> 
> I'm not saying none of this can be implemented, or that the developers
> shouldn't be sympathetic to users. Just that a small group's convenience
> doesn't trump the needs of a larger group, and that the developers
> probably have more reasons not to bother with this than mere laziness or
> a lack of compassion.

not a bad idea at all.

Once you decide to go beyond sharing code with openZFS lots of things
are possible...
And then you can also start abusing the fact that you now can add your
own attributes to the pools and volumes...
Like what zfstools is doing for the backup scenarios.
Than whack a script over it to fill /etc/exports.

--WjW