From owner-freebsd-fs@freebsd.org Wed Aug 31 16:51:07 2016 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 23FD9BCA072 for ; Wed, 31 Aug 2016 16:51:07 +0000 (UTC) (envelope-from brandon.wandersee@gmail.com) Received: from mail-it0-f47.google.com (mail-it0-f47.google.com [209.85.214.47]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EDA25A34; Wed, 31 Aug 2016 16:51:06 +0000 (UTC) (envelope-from brandon.wandersee@gmail.com) Received: by mail-it0-f47.google.com with SMTP id g62so107514599ith.1; Wed, 31 Aug 2016 09:51:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:references:user-agent:from:to:cc:subject :in-reply-to:date:message-id:mime-version; bh=BpTZgxhOvjUbzm3buCMksnauD4uA+CsWj73h+NSXgBo=; b=HORtBsCTpkNV3qPG0OLUpZURq2ZCo1Qi7DVDk7qtNNK/EbQQxScNlZIqJtZifYP3Wk yFbWRKjGcjjK6j+n0JLhv0Q99ABbOmSpbl6+9y96WBq73KTmCg1idvtGHdyED8Z2MwS2 jxgWO9YtVvYtBsptVBgC71VfKZu1Kh9q6sj4JAVjuhBfMbziQlir1FX4kdX63jZ3GYC4 nDia0G5bhe77cbSPDZV8r7ggFw14k3s7lNbpKeUMByoJOJ7DsiqZRf31oJpXjrwrZfia cIrEJiaK+EI6ji7aAdxe07t6X3tI9aznB78TUPn6xi7ezH2ETOxkBMQPkU6RkJhPS38z iqcw== X-Gm-Message-State: AE9vXwN0QYVHdgqQvvmNXj4JP9gRdYaFKzUhIgRrmviKeTXzI50K3mH3wJF8Nsyesczk4A== X-Received: by 10.36.104.73 with SMTP id v70mr15178142itb.12.1472662265626; Wed, 31 Aug 2016 09:51:05 -0700 (PDT) Received: from WorkBox.Home.gmail.com (97-116-18-208.mpls.qwest.net. [97.116.18.208]) by smtp.gmail.com with ESMTPSA id 140sm12704608itl.4.2016.08.31.09.51.04 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 31 Aug 2016 09:51:04 -0700 (PDT) References: <20160829211001.GI1779@mordor.lan> <7a508630-3bcc-2e3d-a78e-8d5e0675ab85@FreeBSD.org> <5aee018f-51aa-2aeb-0964-7bfc88b7bf54@FreeBSD.org> User-agent: mu4e 0.9.16; emacs 24.5.1 From: Brandon J. Wandersee To: Willem Jan Withagen Cc: lev@FreeBSD.org, Julien Cigar , freebsd-fs@freebsd.org Subject: Re: ZFS + NFS + multiple hosts/mount options ..? In-reply-to: Date: Wed, 31 Aug 2016 11:51:05 -0500 Message-ID: <86zinsswzq.fsf@WorkBox.Home> MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Aug 2016 16:51:07 -0000 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 ----------------------------------