[root@todi /tmp]# ls -l /mnt/test1
ls: /mnt/test1: No such file or directory
[root@todi /tmp]# ls -l /mnt/test1
-rw------- 1 root bin 4194304 Apr 13 09:50 /mnt/test1
[root@todi /tmp]# time cp /mnt/test1 .
0.000u 0.130s 0:00.62 20.9% 0+0k 0+0io 79pf+0w
Assuming that "testfile" changed into "test1" by magic and given that I have
yet to look Linux kerenel code, I have a dumb question. The NFS read you do
- is that going across the wire or is it reading from local cache? That you
have only 20.9% of the CPU, that suggests that at least some requests went
over the wire (or waiting on disk). Certainly close-to-open consistancy will
send one GETATTR. There's also the converse dumb question - if the reads are
going over the wire, why wasn't the data cached?
Connectathon's test5 has this incantation that flushes the local cache on
Solaris, Tru64, but may not be a Posix requirement:
#ifdef MMAP
maddr = mmap((caddr_t)0, (size_t)size, PROT_READ,
MAP_PRIVATE, fd, (off_t)0);
if (maddr == NULL) {
error("can't mmap '%s'", bigfile);
exit(1);
}
if (msync(maddr, (size_t)size, MS_INVALIDATE) < 0) {
error("can't invalidate pages for '%s'", bigfile);
exit(1);
}
if (munmap(maddr, (size_t)size) < 0) {
error("can't munmap '%s'", bigfile);
exit(1);
}
#endif
Instead of dealing with disk or /dev/null or /dev/zero overhead, it's a
good idea to have some C hacks that write without refilling buffers and
read without looking at the data. Dd, cp, etc all have side effects that
leave questions about what is really happening.
So, V2 NFS reads REAL fast, just writes slow. V3 Writes REAL fast,
just reads slow.
Maybe V2 caches data locally and V3 doesn't?
-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/