From: Neil Brown Date: Tue, 3 Apr 2007 01:26:58 +0000 (+1000) Subject: NEWS and README updates. X-Git-Tag: nfs-utils-1-1-0-rc2~10 X-Git-Url: https://git.decadent.org.uk/gitweb/?a=commitdiff_plain;h=75fbf31c20fac02e14b6c0cb7dcbfef8286f2ff1;p=nfs-utils.git NEWS and README updates. Particularly details of daemon startup order have been added to README. --- diff --git a/NEWS b/NEWS index fe3571a..ae95c73 100644 --- a/NEWS +++ b/NEWS @@ -1,7 +1,7 @@ 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 @@ -18,7 +18,9 @@ Significant changes for nfs-utils 1.1.0 - March/April 2007 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). @@ -26,18 +28,7 @@ Significant changes for nfs-utils 1.1.0 - March/April 2007 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. diff --git a/README b/README index 7f18118..6cd79c7 100644 --- a/README +++ b/README @@ -45,6 +45,112 @@ simply 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