+ F/ rpc.nfsd
+ Starting nfsd will automatically start lockd. The nfs server
+ will now be fully active and respond to any requests from
+ clients.
+
+ G/ 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
+ idmapd should be started before mounting any NFSv4 filesystems.
+ gssd should be started before mounting any NFS filesystems
+ securely (with Kerberos).
+
+ 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
+
+ Both the server and client need idmapd to be running. If idmapd
+ is started (for the client) before starting nfsd the 'nfsd'
+ filesystem is mounted, then idmapd should be sent a HUP signal
+ afterwards to signal that the server channels should be opened.
+
+
+
+
+Share And Enjoy!
+
+ -- the nfs-utils developers
+ <linux-nfs@vger.kernel.org>