Re: DP2: nfsiod

2002-11-25 Thread Bruce A. Mah
If memory serves me right, Robert Watson wrote:

 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.

I freely declare my ignorance about NFS locking.  :-)

If someone can fix up this part of the release notes to match reality,
I'd be grateful.

Thanks,

Bruce.






msg47446/pgp0.pgp
Description: PGP signature


RE: DP2: nfsiod

2002-11-22 Thread Robert Watson

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