On Sat, Jul 26, 2014 at 9:51 AM, Alan McKinnon <alan.mckin...@gmail.com> wrote: > > NFS uses RPC to do some heavy lifting - I don't know how familiar you > are with this, so here's the quick version: > > When you mount something locally, and need to use the mounted > filesystem, kernel calls are used to get at the data. This works easily > as the source disk is local and the kernel can get to it. With NFS, the > source disk is remote and it's the remote kernel that must do the > accessing. RPC is a way to safely ask a remote kernel to do something > and get a result that behaves identical to a local kernel call. > Obviously, this is rather hard to implement correctly. > > The original RPC was written by Sun and other newer implementations > exist, like libtirpc - to support useful features like not being stuck > with only UDP. That's what the "ti" means - Transport Independant. > > RPC has been in a state of flux for some time and I too have run into > init-script oddities as things change. > > In my case, I have nfs-utils-1.3.0, and rc-update configuredd to start > rpc.statd. This works because > > depend() { > ... > need portmap > ... > } > > and in the init.d file for rpcbind: > > depend() { > ... > provide portmap > } > > So rpcbind starts at boot time and all my nfs mounts JustWork
To confirm the above, for nfs-utils-1.2.9-r3. If I start nfs manually, all the associated daemons start too even though I haven't added them to "default" (although idmapd is started because of "/etc/conf.d/nfs"): # ls -1 /etc/init.d/rpc* /etc/init.d/rpc.idmapd /etc/init.d/rpc.pipefs /etc/init.d/rpc.statd /etc/init.d/rpcbind # rc-update | grep rpc # rc-service nfs start * Starting rpcbind ... [ ok ] * Starting NFS statd ... [ ok ] * Setting up RPC pipefs ... [ ok ] * Starting idmapd ... [ ok ] * Mounting nfsd filesystem in /proc ... [ ok ] * Exporting NFS directories ... [ ok ] * Starting NFS mountd ... [ ok ] * Starting NFS daemon ... [ ok ] * Starting NFS smnotify ... [ ok ] #