testing/review of atomic export update patch

[Andrey Simonenko]

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 <rmacklem at uoguelph.ca>
> > 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.