Re: NFS client performance 1.5 orders of magnitude too slow? (fwd)

Erez Zadok (ezk@cs.columbia.edu)
Tue, 9 Mar 1999 17:59:48 -0500 (EST)


In message <199903092051.NAA06032@sal.cs.utah.edu>, Godmar Back writes:
>
[...]
> Call me dumb, but wouldn't I be better off hacking amd instead of hacking
> the kernel?

Yes, modifying amd is definitely better than kernel hacking (though the
latter is a lot more fun ... :-)

> 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?

It's a bit unusual to find an amd user with control over the local host and
not over the amd maps. At least you're the first to describe such a
situation to me. If you can install a new amd on your host, you can also
make a copy of the nis maps and modify them locally (perhaps using file
maps) but then you won't get updates automatically. There's already too
many overrides in amd:

(1) first amd has some built-in default behavior, which
(2) you can override some of it with command line options, then
(3) it takes some stuff from the amd.conf file, first the [global] section,
and then the individual map, then
(4) in each map it uses the /defaults, then
(5) for each key it uses the options there.

So I'm not sure that yet another override method is necessary, and where it
might fit such that it doesn't confuse things more than they are now.

> 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.)

Yup, it checks if the value is b/t the min/max range, and sets it to either
as needed. Then it also ensures that it's a power of 2.

Erez.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/