Yesss!! knfsd rules!

Steven N. Hirsch (
Mon, 17 Nov 1997 22:10:50 -0500 (EST)


I'm impressed. I applied the fs/namei.c patch and made the one-byte
change to fs/knfsd/nfsfh.c, and bingo!

I've been beating on it for the past half hour without any ugliness. The
only entries in the log would seem to indicate that the "find_fh_dentry()"
code is doing what it's supposed to do. Attached is the entire log from a
complete untar, patch from 2.1.54 --> 2.1.64 and build. This little
workout will almost always trigger NFS problems.

Iozone timings show ~1.5MB/sec. write and ~1.8MB/sec. read on 4k and 8k
records. When the total read length is < 4MB, cacheing drives the numbers
up to around 50MB/sec. <g>. Why is the increased read speed a function of
the new server?? I would think the client code was the bottleneck here,
but I never saw speeds even close to this with the unfsd server.

Must be missing a piece of the puzzle...

Still, given the speed of the network connection (100Mb/sec. ethernet with
only two machines on the subnet) and the boxes, is there potential for
achieving better performance one the code stabilizes?

Raw network transfer rate between the units is ~5-6MB/sec., so the weak
link is still the fs layer, I guess.