Ok. This time I used 2.2.5-ac6 with the 0.5.2 patches and the new
mount from Apr 12th. In the following log, morse is a Sun Ultra 60
(no users, only export is to me) with 100Mb Switched Ethernet. Todi
is a 450Mhz Pentium II with 100Mb Switched Ethernet with above kernel.
[root@todi /tmp]# mount -o rw,rsize=32768,wsize=32768,nfsvers=3 morse:/xtmp /mnt
[root@todi /tmp]# dd if=/dev/zero of=testfile count=8192
8192+0 records in
8192+0 records out
[root@todi /tmp]# ls -l testfile
-rw-r--r-- 1 root root 4194304 Apr 13 08:44 testfile
[root@todi /tmp]# time cp testfile /mnt
0.010u 0.080s 0:00.82 10.9% 0+0k 0+0io 1103pf+0w
[root@todi /tmp]# ls -l /mnt/test1
-rw------- 1 root bin 4194304 Apr 13 09:44 /mnt/test1
[root@todi /tmp]# time cp /mnt/test1 .
0.010u 0.140s 0:08.58 1.7% 0+0k 0+0io 79pf+0w
[root@todi /tmp]#
As you can see, Write performance is perfect. Read performance is
still suffering. For comparison, here are the results with NFSv2
on the same machine. (Writes a bit faster than I recall, maybe the
32k wsize which I had heard was a tad unsafe with V2 NFS)
[root@todi /tmp]# mount -o rw,rsize=32768,wsize=32768 morse:/xtmp /mnt
[root@todi /tmp]# dd if=/dev/zero of=testfile count=8192
8192+0 records in
8192+0 records out
[root@todi /tmp]# ls -l testfile
-rw-r--r-- 1 root root 4194304 Apr 13 09:50 testfile
[root@todi /tmp]# time cp testfile /mnt
0.000u 0.100s 0:02.63 3.8% 0+0k 0+0io 1103pf+0w
[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
So, V2 NFS reads REAL fast, just writes slow. V3 Writes REAL fast,
just reads slow. Let me know if there is anything I can try to
isolate this further.
> Yes. We currently cluster writes in blocks of wsize and then shove
> them out in one fell write, however we do not do this for reading. The
> reason is that we already have the file readahead feature, so the gain
> would not be as great. The clustering would, however, be easy to adapt
> to provide read clustering, so if it turns out useful, I could extend
> it.
Andrew Schretter
Systems Programmer, Duke University
Dept. of Mathematics (919) 660-2866
-
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/