On Oct 14, 2008, at Oct 14, 2008, 1:43 PM, J. Bruce Fields wrote:
On Tue, Oct 14, 2008 at 11:52:52AM -0400, Chuck Lever wrote:
On Oct 14, 2008, at Oct 14, 2008, 5:54 AM, Neil Brown wrote:
I agree that the man page should reflect reality.
Several people have said that, but no-one has suggested what specific
parts of the man page are problematic.
Look at, e.g., the text for "-T":
Disable rpc.nfsd from accepting TCP connections from clients.
It should probably say lockd is unaffected. (If that's what we want.)
That's the problem. I'm not sure how this should behave. I don't
know what the implications are of always having both lockd listeners
on the server.
It seems to me the previous behavior must have been broken -- if -U is
specified, rpc.nfsd prevents the creation of both lockd and nfsd
listeners on UDP, thus we have the same lock recovery problem we have
on the client.
So we must always have a lockd UDP listener on the server, at least.
I would like to understand why we have -T and -U, and whether users of
these options might want lockd to reflect the setting of this option.
Is it acceptable (does it make sense) to have both UDP and TCP
listeners for lockd, while having just one listener for NFSD?
And I don't understand what is being accomplished with the check that
prevents nfsd_init_socks() from starting additional listeners. Neil
did this recently enough that I'm hoping he remembers what the
rationale was and then we can add a comment or two in fs/nfsd/nfsctl.c
to help inform future generations.
Also the wording is a little imprecise, since rpc.nfsd itself doesn't
accept network connections.
--
Chuck Lever
chuck[dot]lever[at]oracle[dot]com
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
