This weekend I built 2.4.20 kernels with and without the NFS-ALL patch
set, and ran some of my standard IO tests on them using TCP mounts.
Good news, they are both stable, and dbench and tiotest numbers are both
very close. What is odd is that the bonnie++ results for the NFS-ALL
patchset are not so good, relative to 2.4.20-vanilla. It looks like there
is a real performance hit, on the order of 2-3x slowness, for the file
creation/listing/deletion test under NFS-ALL. All other operations seem to
be a bit slower as well, although it could be measurement error or bad
luck.
I'm not sure where the bug is, in which patch, so I'm posting to the list
in hopes that someone, probably one of the patch authors, can help me
narrow this down. It's not a huge deal, since 2.4.20-vanilla seems to be
stable and my applications are not dependent on super fast creation times,
but still, this should be fixed.
Results are attached.
My setup:
Client: 2x1.4GHz PIII, 4096MB RAM, 2.4.20 vanilla and NFS-ALL kernels,
100Mbit
Mount: rw,tcp,nfsvers=3,rsize=32768,wsize=32768,intr,hard
Server: Netapp F820, ONTAP 6.2R2, 1000Mbit
thanks,
andrew
>>>>> " " == Andrew Ryan <[email protected]> writes:
> I'm not sure where the bug is, in which patch, so I'm posting
I doubt this is a bug. It's probably a consequence of the ACCESS
patch. Could you try backing that particular patch out of the NFS_ALL
set?
Cheers,
Trond
-------------------------------------------------------
This SF.net email is sponsored by: Microsoft Visual Studio.NET
comprehensive development tool, built to increase your
productivity. Try a free online hosted session at:
http://ads.sourceforge.net/cgi-bin/redirect.pl?micr0003en
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Trond Myklebust wrote:
>>>>>>" " == Andrew Ryan <[email protected]> writes:
> > I'm not sure where the bug is, in which patch, so I'm posting
>
> I doubt this is a bug. It's probably a consequence of the ACCESS
> patch. Could you try backing that particular patch out of the NFS_ALL
> set?
OK, done.
Some of the numbers were better, but the wall clock time was the same.
2.4.20-vanilla comes in at ~43 minutes wall clock run time, but
2.4.20-NFS-ALL and 2.4.20-NFS-ALL-sans-linux-2.4.20-07-access.dif both
came in at 57 minutes wall clock run time.
Results attached. In particular the 'Delete' activity under the
"Sequential Create" test seems very slow, rate of 559/sec with -vanilla
and 11-20/sec with the two NFS patched kernels.