On Tue, 4 Jul 2006, Scott Long wrote:
For what it's worth, I recently spent a lot of time putting FreeBSD 6.1 to
the test as both an NFS client and server in a mixed OS environment. By far
and away, the biggest problems that I encountered with it were due to linux
NFS bugs. CentOS, FC, and SuSE all created huge problems under load, and it
was impossible to get stable results until I started using 2.6.12 and higher
kernels.
I have a variety of theories that I wish I had had time to test. I've seen
hints of problems with READDIRPLUS, with FreeBSD's habit of mapping GETATTR
to ACCESS, and with handle sizes. But in any case, it's been no secret that
Linux has had very severe NFS problems in the past, and that the NetApp
folks have worked very hard over the last year to fix them in the most
recent Linux kernel releases. The only real fault I give FreeBSD is
rpc.lockd. It's pretty much useless in all but trivial circumstances.
Beyond that, make sure you're using a linux kernel that is relatively
recent.
BTW, I noticed yesterday that that IPv6 support committ to rpc.lockd was never
backed out. An immediate question for people experiencing new rpc.lockd
problems with 6.x should be whether or not backing out that change helps.
I set up a simple local testbed for rpc.lockd this morning and have started
running some basic tests. I wasn't able to trivially reproduce rpc.lockd
problems reported for cp -r, although I did bump into another bump in the
memory mapping of zero-length files following creation in the NFS client,
which I've passed on to Mohan.
I think what's needed is a wire-level regression suite, though, in order to
avoid mixing up our rpc.lockd client code with the tests for rpc.lockd's
server. This is something I may be able to start looking at this week,
although it's the usual time trade-off: work on getting audit ready for MFC,
network stack locking and protocol cleanup/bug fixing, or throw rpc.lockd into
the mix as well? If we can demonstrate that backing out the IPv6 change
clearly helps, we need to figure out why it's causing the problem. A casual
read of the change doesn't suggest anything obvious, unfortunately, suggesting
something non-obvious :-(.
Robert N M Watson
Computer Laboratory
University of Cambridge
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"