From owner-freebsd-fs@FreeBSD.ORG Thu Sep 20 12:59:13 2012 Return-Path: Delivered-To: freebsd-fs@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 28AC7106566B; Thu, 20 Sep 2012 12:59:13 +0000 (UTC) (envelope-from simon@comsys.ntu-kpi.kiev.ua) Received: from comsys.kpi.ua (comsys.kpi.ua [77.47.192.42]) by mx1.freebsd.org (Postfix) with ESMTP id 737B88FC12; Thu, 20 Sep 2012 12:59:12 +0000 (UTC) Received: from pm513-1.comsys.kpi.ua ([10.18.52.101] helo=pm513-1.comsys.ntu-kpi.kiev.ua) by comsys.kpi.ua with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1TEgLW-0005iT-6v; Thu, 20 Sep 2012 15:59:10 +0300 Received: by pm513-1.comsys.ntu-kpi.kiev.ua (Postfix, from userid 1001) id 8EC2B1CC23; Thu, 20 Sep 2012 15:59:09 +0300 (EEST) Date: Thu, 20 Sep 2012 15:59:09 +0300 From: Andrey Simonenko To: Rick Macklem Message-ID: <20120920125909.GA9013@pm513-1.comsys.ntu-kpi.kiev.ua> References: <2050472507.821722.1348009974939.JavaMail.root@erie.cs.uoguelph.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2050472507.821722.1348009974939.JavaMail.root@erie.cs.uoguelph.ca> User-Agent: Mutt/1.5.21 (2010-09-15) X-Authenticated-User: simon@comsys.ntu-kpi.kiev.ua X-Authenticator: plain X-Sender-Verify: SUCCEEDED (sender exists & accepts mail) X-Exim-Version: 4.63 (build at 28-Apr-2011 07:11:12) X-Date: 2012-09-20 15:59:10 X-Connected-IP: 10.18.52.101:19601 X-Message-Linecount: 192 X-Body-Linecount: 175 X-Message-Size: 6779 X-Body-Size: 5939 Cc: FS List , Will Andrews , "Justin T. Gibbs" Subject: Re: testing/review of atomic export update patch X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Sep 2012 12:59:13 -0000 On Tue, Sep 18, 2012 at 07:12:54PM -0400, Rick Macklem wrote: > Justin T. Gibbs wrote: > > On Sep 16, 2012, at 3:41 PM, Rick Macklem > > wrote: > > > > > Hi, > > > > > > There is a simple patch at: > > > http://people.freebsd.org/~rmacklem/atomic-export.patch > > > that can be applied to a kernel + mountd, so that the new > > > nfsd can be suspended by mountd while the exports are being > > > reloaded. It adds a new "-S" flag to mountd to enable this. > > > (This avoids the long standing bug where clients receive ESTALE > > > replies to RPCs while mountd is reloading exports.) > > > > At Spectra, we are successfully using the NFSE patch set from > > nfse.sourceforge.net (FreeBSD PR 136865). It addresses > > the ESTALE problem in addition to cleaning up several aspects > > of exports processing. > > > > Have you reviewed the NFSE work? Do you have any issues > > or concerns with it? What is the right path for getting NFSE > > integrated into FreeBSD? > > > I, personally, have not found the time to review it. As such, > I can't state specifics, however there have been concerns w.r.t. > a switch from mountd->nfse resulting in different behaviour when > used with the same /etc/exports file used for mountd. > > Some questions that need to be answered w.r.t. nfse, which I > haven't had the time to do: > - Are the differences listed here significant enough for a > change to be considered a POLA violation? > http://nfse.sourceforge.net/COMPATIBILITY Just to be clear with what is "POLA violation", can somebody who has interest in this topic answer the following questions: Was the following change to mountd considered POLA violation? (this change ignored the semantics of the -alldirs option) http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.sbin/mountd/mountd.c.diff?r1=1.83;r2=1.84 Are the following changes (corrections) to mountd considered POLA violation? http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/170295 http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/170413 > - If the server mount point is /sub1 and the only line > referring to this server volume in /etc/exports looks like: > > /sub1/sub2 client.net > > Does the following mount command work on client.net > # mount -t nfs -o nfsv3 server.net:/sub1 /mnt > when nfse is run with -C using the /etc/exports file? This command will cause "access denied" for the NFSv2/3 clients and NFS server will export /sub1 to NFSv2/3 clients. > This is typically referred to as an "administrative control", > since it is only enforced by mountd for the Mount protocol, > but is considered an important feature by some (rwatson@ > expressed a desire/need for it). Exactly like this. > - Does the nfse patch handle exporting of all file systems types > and, in particular, the `zfs share` case. It does not depend on file system type, a file system just should support NFS. NFSE is integrated as a part of NFS server code, so ZFS snapshots will not be exported automatically. Currently if ZFS file system is exported, then its snapshots are exported as well (not optional BTW) because VFS_CHECKEXP() is used. "zfs share/unshare" modifies /etc/zfs/exports and depending on presence of the /etc/nfs.exports file sends SIGHUP to mountd or calls "nfse -c ..." to update settings dynamically. It is assumed that if ZFS file system is exported via "zfs share", then it is not exported in another file (details in fsshare.c:nfse_update() in src/cddl. 1. Example how mountd after 1.84 of mountd.c understands -alldirs: # cat /etc/exports /cdrom -alldirs # mountd # showmount -e Exports list on localhost: /cdrom Everyone # mount | grep /cdrom # mount -t nfs -o nfsv3 127.0.0.1:/ /mnt # ls /mnt ... # 2. Example how nfse understands /etc/exports with only one line with pathname that is not a mount point: # cat /etc/exports /sub1/sub2 127.0.0.1 # mount | grep /sub1 /dev/md0 on /sub1 (ufs, local) # nfse -C # mount -t nfs -o nfsv3 127.0.0.1:/sub1 /mnt [tcp] 127.0.0.1:/sub1: Permission denied # mount -t nfs -o nfsv3 127.0.0.1:/sub1/sub2 /mnt # ls /mnt file.txt # ls /sub1/sub2 file.txt # showmount -e Exports list on localhost: /sub1 127.0.0.1 # nfse -c show ... Pathname /sub1 (exported) Export specifications: -rw -sec sys -maproot=-2:-2 -host 127.0.0.1 Subdirectories for NFSv2/3: /sub1/sub2 -host 127.0.0.1 ... # 3. Example how nfse understands /etc/exports with one line with -alldirs: # cat /etc/eports /sub1/sub2 -alldirs 127.0.0.1 # mount | grep /sub1 /dev/md0 on /sub1 (ufs, local) # nfse -C # mount -t nfs -o nfsv3 127.0.0.1:/sub1 /mnt [tcp] 127.0.0.1:/sub1: Permission denied # mount -t nfs -o nfsv3 127.0.0.1:/sub1/sub2 /mnt [tcp] 127.0.0.1:/sub1/sub2: Permission denied # showmount -e Exports list on localhost: # nfse -c show ... Pathname /sub1/sub2 File system options: -alldirs Export specifications: -rw -sec sys -maproot=-2:-2 -host 127.0.0.1 Subdirectories for NFSv2/3: /sub1/sub2 -alldirs -host 127.0.0.1 ... # mount /dev/md1 /sub1/sub2 # mount | grep /sub1 /dev/md0 on /sub1 (ufs, local) /dev/md1 on /sub1/sub2 (ufs, local) # mount -t nfs -o nfsv3 127.0.0.1:/sub1 /mnt [tcp] 127.0.0.1:/sub1: Permission denied # mount -t nfs -o nfsv3 127.0.0.1:/sub1/sub2 /mnt # showmount -e Exports list on localhost: /sub1/sub2 127.0.0.1 # nfse -c show ... Pathname /sub1/sub2 (exported) File system options: -alldirs Export specifications: -rw -sec sys -maproot=-2:-2 -host 127.0.0.1 Subdirectories for NFSv2/3: /sub1/sub2 -alldirs -host 127.0.0.1 ... # All examples were checked on 10-CURRENT with recent NFSE. Some lines from the "nfse -c show" command were removed. There is no /var/run/mountd.pid -> /var/run/nfse.pid symlink, so mount does not send SIGHUP to nfse.