On Fri, 22 Nov 2002, John Baldwin wrote:
> On 22-Nov-2002 local.freebsd.current wrote:
> > Having installed DP2 and said NO to NFS client and
> > server in sysinstall (and there's nothing about them
> > in /etc/rc.conf) I see four nfsiod daemons running
> > after the first boot. Are they supposed to be there?
>
> Yes. If you have NFS client support in your kernel they will be there.
> GENERIC has NFS client support enabled by default. Hmm this is kind of
> a policy change as it now means that nfs_client_enable is basically
> useless unless you compile a custom kernel w/o NFS client support in
> which case the startup scripts will attempt to load it as a module for
> you.
Per our phone conversation this morning, the way to think about it is
this:
The only function of nfsiod is to provide asynchronous write-behind
functionality. On -STABLE, even if nfsiod isn't actually running, if the
NFS client code is present in the kernel, NFS will still work. What
nfs_client_enable should do is:
(1) Load the kernel module if it's not already loaded
(2) Tune the kernel module if appropriate
(3) Possibly start rpcbind as a dependency
(4) Possibly start rpc.statd as a dependency
(5) Possibly start rpc.lockd as a dependency
Note that the rpc.lockd support is still experimental in 5.0 for
client-side locking, and as such, might not be good to enable by default.
I notice that in the original message for this thread, there's reference
to release documentation indicating that client side locking isn't
implemented: this is actually not the case. We do implement it now.
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED] Network Associates Laboratories
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
