lkml.org 
[lkml]   [1999]   [Apr]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: NFSv3 client for Linux-2.2.5 ready for alpha testing...
Date

This leads me to believe that the Solaris local UFS read ahead is somehow
mistimed with the NFS read ahead and thus causing a large delay
on the reads. This is just a guess and I'm still working on it.

One thing that confused Tru64 Unix a while back was Sun clients writing
to Tru64 servers. We only support 8KB (or less) I/O sizes, and the Sun
clients really wanted to do 32 KB. So, we'd see the first 8 KB of many
32 KB chunks, then the 2nd 8 KB, then 3rd, then 4th. Then the pattern
would repeat with the next set of I/Os.

One (or both?) of our physical file systems saw this pattern and wrongly
concluded that the client was doing random access I/O, and that lead to
inefficient block allocation. If Linux clients do read ahead, that
might be confusing Solaris. Perhaps the 4 KB I/O size doesn't trigger
readahead. Hmm. If you read a file that you just created on Solaris,
I'd expect that to be in Solaris's cache and it shouldn't need to read
from the disk anyway.

One thing sorely missing from this mail list discussion is tcpdump (or snoop)
data. A good snippet from a tcpdump trace can expose all sorts of
interesting issues.

I understand you're using Solaris, but for the benefit of others,
on Tru64/Digital Unix systems, adding:

options NTP_TIME
options MICRO_TIME
options PACKETFILTER

to the configuration file will build in packet filter support and allow
tcpdump to report timestamps at the microsecond level.

-Ric Werme

--
Eric (Ric) Werme | werme@zk3.dec.com
Compaq Computer Corp. | http://www.cyberportal.net/werme

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

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