Trond Myklebust wrote:
On Fri, 2006-02-24 at 04:14 -0800, Andrew Morton wrote:
Trond Myklebust <[email protected]> wrote:
On Thu, 2006-02-23 at 15:35 -0500, Bryan Fink wrote:
> Hi All. I'm running into a bit of trouble with NFS on 2.6. I see that
> at least Trond thought, mid-January, that "The readahead algorithm has
> been broken in 2.6.x for at least the past 6 months." (
> http://www.ussg.iu.edu/hypermail/linux/kernel/0601.2/0559.html) Anyone
> know if that has been fixed?
No it hasn't been fixed. ...and no, this is not a problem that only
affects NFS: it just happens to give a more noticeable performance
impact due to the larger latency of NFS over a 100Mbps link.
iirc, last time we went round this loop Ram and I were unable to reproduce it.
Does anyone have a testcase?
Yes. A dead simple one
run iozone in sequential read mode on a tcp link w/ rsize == 32k
I'm sure Trond's testcase is much more useful, but for reference, I
thought I'd add that I've been doing my testing with a simple "dd
if=/nfsmount/file of=/dev/null bs=32k". /nfsmount/file is usually 2.5-3
GB, which makes the difference between NFS servers long enough that I
feel safe throwing a "time" in front of the whole command. That is, the
difference is nowhere near millisecond resolution (it's nearer a
minute), so I like to start the test and then walk away to do other things.
Interesting that it's not an NFS-only bug. I assumed it was when I
logged into each server so I could run "dd if=file of=/dev/null bs=32k"
locally. When I did that, both servers gave roughly the same speed.
Sorry I left this bit out of my first email. I assume this example only
illustrates how opaque the code around this problem truly is.
Thanks very much for the help.
-Bryan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]