[lkml]   [1999]   [Mar]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: NFS client performance 1.5 orders of magnitude too slow? (fwd)

A few more quick comments on this issue:

> GNU configure by default will set the $prefix to /usr/local. You can change
> it to match your system w/ --prefix=/usr. I'd prefer to keep the default
> prefix b/c that's what most people are used to.

I knew that, but quite frankly, I don't have the guts to configure
with --prefix=/usr. I doubt many people have. I rather let my
packaging system control what's in /usr.
After all, what are distributions and packaging systems for?

> > The 8,192 byte write test finishes now instantaneously as it should.
> If 8k is better than the default 4k linux 2.2.x now uses, perhaps you can
> argue to Linus to make that the default?

I was talking about the test that wrote 8,192 x 1 byte sequentially.
This test works now that amd doesn't mount with wsize=1k anymore.
Apparently, in order for the write behind code to become effective,
you have to mount at least with a wsize >= 4k.
So from that perspective, there doesn't seem to appear a reason to
change the default wsize from 4k to 8k.

However, the default wsize may be an issue for large files.
I reported that FreeBSD 3.0 takes 6 seconds to write a 12 MB
file where Linux 2.2.3 with wsize=4k takes 14 seconds.
(Btw, FreeBSD 2.2.8 takes only 2.5 seconds for the same file.)

So I tested the Linux client with wsize=8k; it is still a lot slower.
A Linux 2.2.3 client with wsize=8k takes about 30 seconds to write
a 12 MB file (this is with a different server), while a BSD client takes
about 18 seconds with the same server.

I assume this is what Alan is talking about that will be fixed next.

> If you have no control over the amd maps, your only other option would be to
> have your own hacked linux kernel that overrides the default rsize/wsize.
> Note that amd on linux will set the default rsize/wsize based on the running
> kernel's version so if you hack a kernel, you have to hack its nfs to ignore
> what the mount(2) syscall passes it and just set it to 8k. Still the best
> way would be to modify the amd maps to your needs.

Call me dumb, but wouldn't I be better off hacking amd instead of hacking
the kernel?

Also, wouldn't it be *really* nice to have a feature in am-utils to
override *both* the wsize setting given in a NIS map *and* the default
setting as given by a particular Linux kernel?

I assume that the Linux kernel honors wsize requests that are not the
default. (fs/nfs/inode.c: nfs_block_size seems to suggest that it does.)


- Godmar

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:50    [W:0.067 / U:0.192 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site