From owner-freebsd-fs@freebsd.org Mon Aug 3 12:25:18 2015 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 BBE5D9B1E0B for ; Mon, 3 Aug 2015 12:25:18 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 5B9C0D54; Mon, 3 Aug 2015 12:25:17 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A2AGAwAgXb9V/61jaINbGQEBAYNSaQaDHbktCYFdHQqFL0oCgWAUAQEBAQEBAYEKhCQBAQEDAQEBICsgCxACAQgYAgINGQICJwEJJgIECAcEARwEiA0Ns3+VYQEBAQEBAQQBAQEBAR2BIoothC8HAQEFFzQHgmmBQwWUeYR7gmKCEYQlRoZukEsCJoIOHBWBWiIxB34JFyOBBAEBAQ X-IronPort-AV: E=Sophos;i="5.15,601,1432612800"; d="scan'208";a="228782695" Received: from nipigon.cs.uoguelph.ca (HELO zcs1.mail.uoguelph.ca) ([131.104.99.173]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 03 Aug 2015 08:25:14 -0400 Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id C35E615F542; Mon, 3 Aug 2015 08:25:14 -0400 (EDT) Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id iWkxCeA3Qb-e; Mon, 3 Aug 2015 08:25:14 -0400 (EDT) Received: from localhost (localhost [127.0.0.1]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id F233415F55D; Mon, 3 Aug 2015 08:25:13 -0400 (EDT) X-Virus-Scanned: amavisd-new at zcs1.mail.uoguelph.ca Received: from zcs1.mail.uoguelph.ca ([127.0.0.1]) by localhost (zcs1.mail.uoguelph.ca [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id mnlUEnp0QrPa; Mon, 3 Aug 2015 08:25:13 -0400 (EDT) Received: from zcs1.mail.uoguelph.ca (zcs1.mail.uoguelph.ca [172.17.95.18]) by zcs1.mail.uoguelph.ca (Postfix) with ESMTP id D49B615F542; Mon, 3 Aug 2015 08:25:13 -0400 (EDT) Date: Mon, 3 Aug 2015 08:25:13 -0400 (EDT) From: Rick Macklem To: Julian Elischer Cc: freebsd-fs@freebsd.org Message-ID: <67101638.8226696.1438604713620.JavaMail.zimbra@uoguelph.ca> In-Reply-To: <55BEE668.3080303@freebsd.org> References: <795246861.20150801140429@serebryakov.spb.ru> <1363497421.7238055.1438428070047.JavaMail.zimbra@uoguelph.ca> <1593307781.20150801143052@serebryakov.spb.ru> <55BEE668.3080303@freebsd.org> Subject: Re: NFS & ZFS: how to export whole FS hierarhy to mount it with one command on client? MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.95.12] X-Mailer: Zimbra 8.0.9_GA_6191 (ZimbraWebClient - FF34 (Win)/8.0.9_GA_6191) Thread-Topic: NFS & ZFS: how to export whole FS hierarhy to mount it with one command on client? Thread-Index: 2RZ+wToGPDqqBYcRYZz0ktt3TrYzSg== X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 12:25:18 -0000 Julian Elischer wrote: > On 8/1/15 7:30 PM, Lev Serebryakov wrote: > > Hello Rick, > > > > Saturday, August 1, 2015, 2:21:10 PM, you wrote: > > > >> To mount multiple file systems as one mount, you'll need to use NFSv4. I > >> believe > >> you will have to have a separate export entry in the server for each of > >> the file > >> systems. > > So, /etc/exports needs to have BOTH v3-style exports & V4: root of tree > > line? > > OR you can have a non-standard patch that pjd wrote to do recursive > mounts of sub-filesystems. > it is not supposed to happen according to the standard but we have > found it useful. > Unfortnately it is written agains the old NFS Server. > > Rick, if I gave you the original pjd patch for the old server, could > you integrate it into the new server as an option? > A patch like this basically inserts the file system volume identifier in the high order bits of the fileid# (inode# if you prefer), so that duplicate fileid#s don't show up in a "consolidated file system" (for want of a better term). It also replies with the same "fake" fsid for all volumes involved. I see certain issues w.r.t. this: 1 - What happens when the exported volumes are disjoint and don't form one tree? (I think any just option should be restricted to volumes that form a tree, but I don't know an easy way to enforce that restriction?) 2 - It would be fine at this point to use the high order bits of the fileid#, since NFSv3 defines it as 64bits and FreeBSD's ino_t is 32bits. However, I believe FreeBSD is going to have to increase ino_t to 64bits soon. (I hope such a patch will be in FreeBSD11.) Once ino_t is 64bits, this option would have to assume that some # of the high order bits of the fileid# are always 0. Something like "the high order 24bits are always 0" would work ok for a while, then someone would build a file system large enough to overflow the 40bit (I know that's a lot, but some are already exceeding 32bits for # of fileids) field and cause trouble. 3 - You could get weird behaviour when the tree includes exports with different export options. This discussion includes just that and NFSv3 clients don't expect things to change within a mount. (An example would be having part of this consolidated tree require Kerberos authentication. Another might be having parts of the consolidated tree use different uid mapping for AUTH_SYS.) 4 - Some file systems (msdosfs ie. FAT) have limited capabilities w.r.t. what the NFS server can do to the file system. If one of these was imbedded in the consolidated tree, then it could cause confusion similar to #3. All in all, the "hack" is relatively easy to do, if: You use one kind of file system (for example ZFS) and make everything you are exporting one directory tree which is all exported in a compatible way. You also "know" that all the fileid#s in the underlying file systems will fit in the low order K bits of the 64bit fileid#. My biggest concern is #2, once ino_t becomes 64bits. If the collective thinks this is a good idea despite the issues above and can propose a good way to do it. (Maybe an export flag for all the volumes that will participate in the "consolidated file system"? The exports(5) man page could then try to clearly explain the limitations of its use, etc. Even with that, I suspect some would misuse the option and cause themselves grief.) Personally, since NFSv4 does this correctly, I don't see a need to "hack it" for NFSv3, but I'll leave it up to the collective. rick ps: Julian, you might want to repost this under a separate subject line, so people not interested in how ZFS can export multiple volumes without separate entries will read it. > > > > _______________________________________________ > freebsd-fs@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscribe@freebsd.org" >