Date: Wed, 31 Aug 2016 11:51:05 -0500 From: Brandon J. Wandersee <brandon.wandersee@gmail.com> To: Willem Jan Withagen <wjw@digiware.nl> Cc: lev@FreeBSD.org, Julien Cigar <julien@perdition.city>, freebsd-fs@freebsd.org Subject: Re: ZFS + NFS + multiple hosts/mount options ..? Message-ID: <86zinsswzq.fsf@WorkBox.Home> In-Reply-To: <e544f452-2322-b62b-acf3-5dbf0e50e998@digiware.nl> References: <20160829211001.GI1779@mordor.lan> <7a508630-3bcc-2e3d-a78e-8d5e0675ab85@FreeBSD.org> <dab0002c-61d7-3bf9-cadd-faf564d1f413@digiware.nl> <5aee018f-51aa-2aeb-0964-7bfc88b7bf54@FreeBSD.org> <e544f452-2322-b62b-acf3-5dbf0e50e998@digiware.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
--
:: Brandon J. Wandersee
:: brandon.wandersee@gmail.com
:: --------------------------------------------------
:: 'The best design is as little design as possible.'
:: --- Dieter Rams ----------------------------------
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86zinsswzq.fsf>