Linux Test Project

Networking: NFSv3


January 31, 2002

Introduction

This document summarizes the NFSv3 test results of the IBM Linux Technology Center Test Team. It includes the test approach, unresolved issues, environment, test cases, and observations of NFSv3. It identifies areas where additional testing would be useful.

Test approach

Connectathon is a network proving ground allowing vendors to test their interoperability solutions, with special emphasis on NFS and Internet protocols. They provide a testsuite for NFS that covers functionality of the protocol, as well as adherence to the interoperability specifications described in the RFC.  This testsuite, along with ported AIX and newly developed testcases, were included in the NFS testing.  Certain applicable filesystem tests from the LTP were also included in this test effort.

Exit criteria

All testcases have been executed, and any defects found have been posted.

Unresolved issues

1. TCP connections could not be used.
The NFS code tested did not have TCP connections as an option, so only UDP was tested.

Areas for further testing

This NFS testing should be ran over TCP connections. This code was just recently added.

Test environment

This section details the distributions, and kernel versions, and defines the hardware configurations used during testing.

Distributions

Initial test efforts focused on commercially available distributions. The LTC is continually evaluating its' test environment and may add additional distributions in the future. The distributions and releases for the test effort were as follows:

Kernels

2.4.14 kernel and nfs-utils 0.3.3.

Hardware configurations

Name Processor Memory Storage Other
UP-1 Pentium III 866Mhz  256 MB 30 GB N/A
UP-2 Pentium III 866Mhz  256 MB 30 GB N/A
4-way 4 X IBM PowerPC 604e 166MHz 2 GB 36 GB Running AIX

Test cases and observations


Focus Testing
Location: http://ltp.sf.net
Description: NFSv2 is assumed to be a stable and reliable product.  Regression testing on NFSv2 was carried out and the results formed the baseline.  These tests covered the basic procedures allowed within an NFS filesystem and the system commands associated with NFS. The same tests were tested against the latest release of NFSv3, along with new tests created for the new functionalities and features included with this version.
Target Test Duration: 24 Hours
Average Test Duration: 24 Hours
Hardware: UP-1 and UP-2
Kernel: 2.4.14
Distributions: Red Hat 7.2 and SuSE 7.3
Parameters: All NFS connections use UDP only.
Observations:
Test Name Number
of Passes
Number
of Fails
Total
Iterations
Success
Rate
Connectathon 351 0 351 100%
nfslock01 346 5 351 * 98.58%
nfsstress 351 0 351 100%
nfs01 352 0 351 100%
nfs02 352 0 351 100%
nfs03 351 0 351 100%
nfsstat 351 0 351 100%
* The failures of nfslock01 are due to an inconsistency between the input file used and output file created during the test.  However, when run manually, the error is randomly reported, but not substanstiated.  A manual 'diff' and visual inspection of the two files shows no differences.  This is a race condition between the 'diff' section of the test starting before the lock portion of the test finishes.  I added a short sleep before the 'diff' and re-ran the nfslock01 test for 24 hours.  The test passed 100% of the time for 12315 iterations.


Integration Testing: Focus Testing
Location: http://ltp.sf.net
Description: Integration into a customer scenario consists of a number of clients all mounting from one to two servers.  Most customer implementations of NFS usually include multiple operating systems within their NFS client-server model.  AIX machines were used as clients and as a server to represent a multi-system environment.  Various applications, as well as tests, were ran on the NFS mounted filesystems to represent customer workloads.
Target Test Duration: 48 Hours
Average Test Duration: 48 Hours
Hardware: UP-1, UP-2 , 4-way
Kernel: 2.4.14
Distributions: Red Hat 7.2 and SuSE 7.3
Parameters: All NFS connections use UDP only.
Observations:
  • The "nfs03" test ran continuously and successfully for the entire 48 hours on 50 directories with 25 files in each.
  • The Connecathon "Special" test of a write/read of a 30MB file failed with an Input/Output Error for NFSv3.  The test passes using an NFSv2 mount, and has also passed when running to Linux servers using both NFSv2 and NFSv3. If AIX is the problem, more will be known at the end of the Stress test.
  • The LTP's NFS Tests ran for 48 hours with all tests passing 100%, except "nfslock01".  This test passed 74% of the time.  The "nfslock01" test will be isolated as part of the Stress test to help figure out the reason for its failures.


Stress Testing:

Test #1

Test #1

Test #2

Test #2
Location: http://ltp.sf.net
Description: The robustness of NFSv3 is defined by how well it handles large amounts of data and traffic between multiple clients, while other tasks are being performed on the system.  LTP kernel tests were ran on the server, while NFS traffic was generated by various applications and tests ran on multiple clients. 
Target Test Duration: Test1 - 96 Hours
Test2 - 96 Hours
Average Test Duration: Test1 - 96 Hours
Test2 - 168 Hours
Hardware: UP-1 , UP-2 , 4-way
Kernel: 2.4.14
Distributions: Red Hat 7.2 and SuSE 7.3
Parameters: All NFS connections use UDP only.
Observations: Test #1
  • All 4 tests ran continuously and successfully at a 2047 Mb filesize setting for 72 hours.
  • The Bonnie test themselves, along with the rpciod daemon (client side NFS process) and all nfsd daemons (server side NFS processes) accounted for average CPU load of  80%.


Test #2

  • UP-1 -> UP-2
    • Bonnie was able to generate enough traffic to help occupy the CPU at approx. 80% load, with about 30% going to the rpciod process.  The rpciod deamon is the client-side NFS process daemon.  Bonnie ran successfully without any recorded errors.
    • The nfslock01 test completed 111586 iterations with 72178 passes and 39408 failures, for a success rate of * 64.68%.
  • UP-2 -> 4-way
    • Bonnie was able to generate enough traffic to help occupy the CPU at approx. 80% load, with about 28% going to the rpciod process and 15% going to the nfsd process.  The rpciod deamon is the client-side NFS process daemon, and the nfsd daemon is the server-side NFS process.  Bonnie ran successfully without any recorded errors.
    • The nfslock01 test completed 110134 iterations with 69074 passes and 41060 failures, for a success rate of *62.72%.
  • 4-way -> UP-1
    • The NFS server daemon, nfsd, occupied 31% of the Red Hat machine's CPU.  This high usage was obtained by lowering the number of server daemons from the default number of 8 down to 1, and running 2 copies of the nfs03 test (one over NFSv2 and the other over NFSv3).
  • The failures of nfslock01 are due to an inconsistency between the input file used and output file created during the test.  However, when ran manually, the error is randomly reported, but not substanstiated.  A manual 'diff' and visual inspection of the two files shows no differences.  This is a race condition between the 'diff' section of the test starting before the lock portion of the test finishes.  I added a short sleep before the 'diff' and re-ran the nfslock01 test for 24 hours.  The test passed 100% of the time for 12315 iterations.
Test team:
Robbie Williamson

Sourceforge.net  Last modified on: August 02, 2006 - 17:13:16 UTC.
Theme: