Hi Neil-
On Oct 12, 2008, at Oct 12, 2008, 7:15 PM, Neil Brown wrote:
On Saturday October 4, bfields@xxxxxxxxxxxx wrote:
On Fri, Oct 03, 2008 at 05:15:14PM -0400, Chuck Lever wrote:
Hi Bruce, Neil-
Here's my initial proposal to address the NFSv2/v3 lock recovery
issue
that results from having no UDP lockd listener.
Comments? Did I miss anything?
Looks fine; I can't see any problem. So I've applied to for-2.6.28.
(An ack from Neil would be reassuring, though, if he gets a chance.)
Sorry for my tardiness. September was a very hectic month for me.
One consequence of this change is that lockd always listens on TCP
even if NFSD and NFS are only using UDP.
Do we care? I suspect not.
The server side usually has to start both anyway, so I thought making
both sides work the same way was slightly nicer than keeping the
"proto" argument to lockd_up(), and the run-time cost on the client is
fairly minimal. Plus, the overall trend is away from NFS over UDP,
and towards NFS over TCP. UDP is legacy, and TCP is the common case,
going forward, so it's likely the TCP listener will nearly always be
running anyway.
However, do we care about the -T and -U options on rpc.nfsd affecting
how server-side lockd works? Maybe that is a valid reason to keep the
"proto" argument to lockd_up().
An alternative fix to the problem would be to always listen on UDP and
only listen on TCP if it was requested. This would probably be a
smaller code change, and might in some sense be more flexible.
Will we ever want to talk NLM over any other protocol? RDMA?
Is UDP6 a different protocol in this context? I suspect not.
I guess I have a small leaning towards just always listening on UDP
and leaving everything else the same, but it is small, not strong. So
unless either of you lean the same way I'm happy to give my
Acked-By: NeilBrown <neilb@xxxxxxx>
to the current patches.
Thanks for the review.
--
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
