-to build the source and binary RPMs.
-
-If your mount from util-linux is too old, you will need 2 patches:
-
-ftp://ftp.linuxnfs.sourceforge.org/pub/nfs/util-linux-2.9o-mount-nfsv3.patch
-ftp://ftp.linuxnfs.sourceforge.org/pub/nfs/util-linux-2.9w-mount-nfsv3try.patch
-
-Thanks.
-
-
-H.J.
-hjl@lucon.org
-12/06/99
+ 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 of SPKM3).
+
+ 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>