lkml.org 
[lkml]   [2000]   [Oct]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: v2.4.0test9 NFSv3 server woes Linux-->Solaris
On Thu, Oct 05, 2000 at 11:38:26AM -0400, Bill Rugolsky Jr. wrote:
> On Thu, Oct 05, 2000 at 04:58:39PM +0200, David Weinehall wrote:
> > Using the NFSv3 server in the v2.4.0test9 kernel (I haven't tested any
> > earlier v2.3.xx or v2.4.0testx kernels) I'm having problems with
> > (for instance) compile glib.
> >
> > The setups I've tried are:
> >
> > wsize = rsize = 1kB
> > Linux NFSv3 server --> Linux NFSv3 client (UDP mounted) -- WORKS
> >
> > wsize = rsize = 32kB
> > Linux NFSv3 server --> Solaris NFSv3 client (UDP mounted) -- BROKEN!
> > Linux NFSv3 server --> Solaris NFSv3 client (TCP mounted) -- BROKEN!
> >
> > wsize = rsize = 2kB
> > Linux NFSv3 server --> Solaris NFSv3 client (UDP mounted) -- BROKEN!
> > Linux NFSv3 server --> Solaris NFSv3 client (TCP mounted) -- BROKEN!
>
> What do you mean by "BROKEN" ? Anything in syslog? tcpdumps?

Broken as in something is incorrectly transfered. Nothing in the
syslog. It's as if some special combination of data makes the transfer
to break, because the build breaks in the same place for each compile.
And YES, I've tried compiling the same source locally (no trouble),
and mounted Solaris --> Linux, without any problems.

> Why not test wsize=rsize=1K for the Linux/Solaris combo?

Because the wsize=rsize shouldn't be the issue here. And if this really
is what breaks the kernel, something is REALLY broken.

> Also, I was unaware that TCP server was supposed to work in 2.4.0-test9.
> (It isn't in the 2.2.x patches.) Are you sure that Solaris is not falling
> back to UDP mounts?

Every NFS client we run in our network mounts as UDP, so I'm pretty
convinced, yes. The TCP NFS is newly added to v2.4.xx if I'm not all
wrong, and I definitely don't expect it to work properly. I DO expect
UDP to work, however.

> > Oh, by the way, is there ANY sane reason whatsoever behind the decision
> > that the Linux NFSv3 client in the v2.2.18pre15 kernel defaults to wsize
> > = rsize = 1kB and the NFSv3 client in v2.4.0test9 defaults to
> > wsize = rsize = 4kB?! Every (?) other implementation of NFSv3 defaults
> > to 32kB... At least when mounting Solaris NFSv3 server --> Linux NFSv3
> > client, 32kB rsize & wsize works perfectly fine (at least for
> > v2.2.18pre15, but I hope that v2.4.0test9 isn't worse in this regard.)
>
> The conservatism is similar to that for IDE tuning: many folks have
> broken hardware/drivers/networks, and sizes above 1K result in
> fragmentation/potential packet loss/RPC timeouts/write errors/corruption.
> So for 2.2.x, Alan has decreed 1K size. 2.4.0-test is a bit more aggressive.

4kB isn't aggresive. 4kB is VERY conservative. Both gives very bad
performance.

> 32K is fine, if you are using TCP. But I just went through a day-long
> session with NetApp after they updated their default UDP size from 8K
> to 32K. 32K UDP == 23 fragments. On a switched network that may be
> fine, but with a hub and router, it is seeming death. Our Solaris
> clients were generating numerous RPC timeouts on writes. After setting
> the NetApp F720 server default back to 8K, the timeouts went away.
>
> You may want to take this over to nfs@sourceforge.net; also, tcpdumps
> are helpful.

Well, the problem is that Linux doesn't generate any output that informs
the user that the system defaults to a rsize/wsize that differs from
what is common, that is, 32 kB. And as I said, I know of no other OS
that defaults to any other blocksize for NFSv3.


/David
_ _
// David Weinehall <tao@acc.umu.se> /> Northern lights wander \\
// Project MCA Linux hacker // Dance across the winter sky //
\> http://www.acc.umu.se/~tao/ </ Full colour fire </
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:39    [W:0.137 / U:0.512 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site