Significant changes for nfs-utils 1.1.0 - March/April 2007
- rpc.lockd is gone. One 3 old kernel releases need it.
- - /sbin/{u,}mount.nfs{,4} is now installed so 'mount' will
+ - /sbin/{u,}mount.nfs{,4} are now installed so 'mount' will
use these to mount nfs filesystems instead of internal code.
+ mount.nfs will check for 'statd' to be running when mounting
a filesystem which requires it. If it is not running it will
if you kill and restart it, it will restore that state and
continue working correctly.
+ statd makes more use of DNS lookup and should handle
- multi-homed peers better.
+ multi-homed peers better. In particular, files in
+ /var/lib/nfs/sm/ are named with the Full Qualified Domain Name
+ if available.
- If you export a directory as 'crossmnt', all filesystems
mounted beneath are automatically exported with the same
options (unless explicitly exported with different options).
no_subtree_check.
- By default the system 'rpcgen' is used while building
nfs-utils rather than the internal one.
-
-
-Further notes on statd:
-
- statd should be installed in /usr/sbin, not /sbin.
- If you need to mount /usr via nfs, use 'nolock'
-
- At boot time, run "/usr/sbin/sm-notify".
- Run "statd" only when starting the NFS server.
- "statd" should be run before starting the NFS server.
- You do not need to start statd at boot time incase an
- NFS filesystem is mounted. mount.nfs will take care of that.
-
- Make sure /usr/sbin/start-statd will run statd with required
- arguments.
+ - Exportfs will warn if you try to export a filesystem that does
+ not support NFS export.
+ - Comprehensive notes on startup dependencies have been added
+ to the README file.
Finally, build as usual as above.
+3. DAEMON STARTUP ORDER
+
+This nfs-utils packages does not provide any scripts for starting
+various daemons as mast distributions replace them with their own, so
+any scripts we package would not get much testing.
+Instead, we explain the dependencies involved in startup so that
+scripts can be written to work correctly.
+
+3.0 PREREQUISITES
+
+ Name service (host name lookup) should be working before any
+ NFS services are started.
+
+ "portmap" must be running before any NFS services (server or
+ client) are started.
+
+ Normally network interfaces should be configured first as well,
+ though this isn't critical for the NFS server (providing name
+ service is handled locally).
+
+3.1. SERVER STARTUP
+
+
+ A/ mount -t nfsd /proc/fs/nfsd
+ This filesystem needs to be mount before most daemons,
+ particularly exportfs, mountd, svcgssd, idmapd.
+ It could be mounted once, or the script that starts each daemon
+ could test if it is mounted and mount it if not.
+
+ B/ svcgssd ; idmapd
+ These supply services to nfsd and so should be started before
+ rpc.nfsd. Where they come between mounting the nfsd filesystem
+ and starting the nfsd server is not important.
+ idmapd is only need for NFSv4 support.
+
+ C/ exportfs -av ; rpc.mountd
+ If it important that exportfs be run before mountd so that
+ mountd is working from current information (in
+ /var/lib/nfs/etab).
+ It is also important that both of these are run before
+ rpc.nfsd.
+ If not, any NFS requests that arrive before mountd is started
+ will get replied to with a 'Stale NFS File handle' error.
+
+ D/ rpc.statd --no-notify
+ It is best if statd is started before nfsd though this isn't
+ critical. Certainly it should be at most a few seconds after
+ nfsd.
+ When nfsd starts it will start lockd. If lockd then receives a
+ lock request it will communicate with statd. If statd is not
+ running lockd will retry, but it won't wait forever for a
+ reply.
+ Note that if statd is started before nfsd, the --no-notify
+ option must be used. If notify requests are sent out before
+ nfsd start, clients may try to reclaim locks and, on finding
+ that lockd isn't running, they will give up and never reclaim
+ the lock.
+ rpc.statd is only needed for NFSv2 and NFSv3 support.
+
+ E/ rpc.nfsd
+ Starting nfsd will automatically start lockd. The nfs server
+ will now be fully active and respond to any requests from
+ clients.
+
+ F/ sm-notify
+ This will notify any client which might have locks from before
+ a reboot to try to reclaim their locks. This should start
+ immediately after rpc.nfsd is started so that clients have a
+ chance to reclaim locks within the 90 second grace period.
+ sm-notify is only needed for NFSv2 and NFSv3 support.
+
+
+3.2. CLIENT STARTUP
+
+ A/ sm-notify
+ This should be run shortly after boot and before any NFS
+ filesystems are mounted with remote-locking support -
+ filesystems can be mounted with "-o nolock" before sm-notify.
+ This is appropriate for '/', '/usr', and '/var'.
+
+ B/ gssd ; idmapd
+ (I need some guidance here).
+
+ C/ statd should be run before any NFSv2 or NFSv3 filesystem is
+ mounted with remote locking (i.e. without -o nolock).
+ 'mount' will try to use "/usr/sbin/start-statd" to start statd
+ if it is not already running, so there is no need to explicitly
+ start statd in boot-time scripts.
+
+3.3. SERVER/CLIENT INTERACTIONS
+
+ A/ sm-notify
+ Both the server and the client need sm-notify to be run.
+ It should be run after the NFS server is started, but before
+ and NFS filesystems are mounted with remote locking.
+
+ B/ rpc.statd
+ Both the server and the client need rpc.statd to be running.
+ Each should try to start when they need it.
+
+ C/ idmapd
+ (I need some guidance here).
+
+
+
+
Share And Enjoy!
-- the nfs-utils developers
projects / nfs-utils.git / commitdiff