lkml.org 
[lkml]   [1997]   [Nov]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectYesss!! knfsd rules!
Bill,

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.

Steve



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