Messages in this thread | | | From | Eric Werme USG <> | Subject | Re: NFSv3 client for Linux-2.2.5 ready for alpha testing... | Date | Thu, 15 Apr 1999 15:54:15 -0400 |
| |
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/
| |