Provided by: nfs-kernel-server_1.2.0-4ubuntu4_i386 bug

NAME

       nfsd - special filesystem for controlling Linux NFS server

SYNPOSIS

       mount -t nfsd nfsd /proc/fs/nfsd

DESCRIPTION

       The nfsd filesytem is a special filesystem which provides access to the
       Linux NFS server.  The filesystem consists of a single directory  which
       contains a number of files.  These files are actually gateways into the
       NFS server.  Writing to them can affect the server.  Reading from  them
       can provide information about the server.

       This  file  system  is  only  available  in  Linux 2.6 and later series
       kernels (and in the later parts of the 2.5 development  series  leading
       up to 2.6).  This man page does not apply to 2.4 and earlier.

       As  well  as  this  filesystem,  there are a collection of files in the
       procfs filesystem (normally mounted at /proc) which are used to control
       the NFS server.  This manual page describes all of these files.

       The exportfs and mountd programs (part of the nfs-utils package) expect
       to find this filesystem mounted at /proc/fs/nfsd or  /proc/fs/nfs.   If
       it  is  not  mounted,  they  will fall-back on 2.4 style functionality.
       This  involves  accessing  the  NFS  server  via  a  systemcall.   This
       systemcall is scheduled to be removed after the 2.6 kernel series.

DETAILS

       The three files in the nfsd filesystem are:

       exports
              This  file  contains  a  list  of filesystems that are currently
              exported and  clients  that  each  filesystem  is  exported  to,
              together    with   a   list   of   export   options   for   that
              client/filesystem   pair.     This    is    similar    to    the
              /proc/fs/nfs/exports  file  in  2.4.   One  difference is that a
              client doesn’t necessarily correspond to just one host.  It  can
              respond  to  a  large collection of hosts that are being treated
              identically.

              Each line of the file contains a path name, a client name, and a
              number  of  options  in parentheses.  Any space, tab, newline or
              back-slash character in the path name or  client  name  will  be
              replaced  by  a  backslash  followed by the octal ASCII code for
              that character.

       threads
              This  file  represents  the  number  of  nfsd  thread  currently
              running.   Reading  it will show the number of threads.  Writing
              an ASCII decimal number will cause the number of threads  to  be
              changed  (increased  or  decreased as necessary) to achieve that
              number.

       filehandle
              This is a somewhat unusual file  in that what is  read  from  it
              depends  on  what  was  just  written  to  it.   It  provides  a
              transactional interface where a program can open the file, write
              a  request, and read a response.  If two separate programs open,
              write, and read at the same time, their  requests  will  not  be
              mixed up.

              The  request  written  to  filehandle should be a client name, a
              path name, and a number of bytes.  This should be followed by  a
              newline,  with  white-space  separating  the  fields,  and octal
              quoting of special characters.

              On writing this, the  program  will  be  able  to  read  back  a
              filehandle  for  that path as exported to the given client.  The
              filehandles length will be at most the number of bytes given.

              The filehandle will be represented in hex with a leading ’\x’.

       The directory /proc/net/rpc in the procfs filesystem contains a  number
       of  files  and  directories.   The files contain statistics that can be
       display using the nfsstat program.  The directories contain information
       about  various  caches  that  the NFS server maintains to keep track of
       access  permissions  that  different   clients   have   for   different
       filesystems.  The caches are:

       auth.domain
              This  cache maps the name of a client (or domain) to an internal
              data structure.  The only access that is possible  is  to  flush
              the cache.

       auth.unix.ip
              This cache contains a mapping from IP address to the name of the
              authentication domain that the ipaddress should  be  treated  as
              part of.

       nfsd.export
              This  cache  contains  a  mapping  from  directory and domain to
              export options.

       nfsd.fh
              This cache contains a  mapping  from  domain  and  a  filesystem
              identifier to a directory.   The filesystem identifier is stored
              in the filehandles and consists of a number indicating the  type
              of  identifier  and a number of hex bytes indicating the content
              of the identifier.

       Each directory representing a cache can hold from 1 to 3  files.   They
       are:

       flush  When  a number of seconds since epoch (1 Jan 1970) is written to
              this file, all entries in  the  cache  that  were  last  updated
              before  that  file  become  invalidated and will be flushed out.
              Writing 1 will flush everything.  This is  the  only  file  that
              will always be present.

       content
              This file, if present, contains a textual representation of ever
              entry in the cache, one per line.  If an entry is still  in  the
              cache  (because it is actively being used) but has expired or is
              otherwise invalid, it will be presented as  a  comment  (with  a
              leading hash character).

       channel
              This  file,  if  present,  acts  a  channel for request from the
              kernel-based nfs server to be passed to a user-space program for
              handling.

              When the kernel needs some information which isn’t in the cache,
              it makes a line appear in the channel file giving  the  key  for
              the  information.   A  user-space program should read this, find
              the answer, and write a line containing the key, an expiry time,
              and the content.  For example the kernel might make
                   nfsd 127.0.0.1
              appear in the auth.unix.ip/content file.  The user-space program
              might then write
                   nfsd 127.0.0.1 1057206953 localhost
              to indicate that 127.0.0.1 should map to localhost, atleast  for
              now.

              If  the  program uses select(2) or poll(2) to discover if it can
              read from the channel then it will never see and end-of-file but
              when  all  requests  have  been  answered,  it  will block until
              another request appears.

       In the /proc filesystem there are 4 files that can be used  to  enabled
       extra tracing of nfsd and related code.  They are:
            /proc/sys/sunrpc/nfs_debug
            /proc/sys/sunrpc/nfsd_debug
            /proc/sys/sunrpc/nlm_debug
            /proc/sys/sunrpc/rpc_debug
       They  control  tracing  for the NFS client, the NFS server, the Network
       Lock  Manager  (lockd)  and  the  underlying  RPC  layer  respectively.
       Decimal  numbers  can  be  read  from  or written to these files.  Each
       number represents a bit-pattern where bits that are set  cause  certain
       classes  of  tracing to be enabled.  Consult the kernel header files to
       find out what number correspond to what tracing.

SEE ALSO

       rpc.nfsd(8), exports(5), nfsstat(8), mountd(8) exportfs(8).

AUTHOR

       NeilBrown

                                  3 July 2003                          nfsd(7)