readme

早期freebsd实现

#
#	@(#)README	1.11 90/01/03 NFS Rev 2 Testsuite
#
NFS and Connectathon are trademarks of Sun Microsystems, Inc.



Introduction to the NFS Revision 2 Testsuites
---------------------------------------------

These directories contain programs that can be used to test an implementation
 of Revision 2 of the NFS Protocol.  The tests run on a UNIX client and test 
server and client functions.  They are divided into three groups:

	basic   - basic NFS operations tests 
	general - general file system tests
	special - tests that poke certain common problem areas

This README is divided into six sections.  The first section is the introd-
uction,  which you are reading now.  That is followed by a description of 
what you have to do before you run the testsuites on your machine.  Then 
comes a description of how the testsuites are run in general followed by a 
description of how they are used at Connectathon.  The last sections describes 
what each test does in detail.

This testsuite should run on both BSD and System V based systems.
The System V port of the Connectathon Testsuite is provided courtesy
of the Software Technologies Group, INTERACTIVE Systems Corporation,
1901 N. Naper Blvd., Naperville, IL. 60563


Preparing to run the Testsuites
-------------------------------

To prepare to run the testsuites on your machine,  change directories to the 
highest level testsuite directory (it should be the same one that contains 
this README file),  and type "make" to compile the test programs.  If you are 
not sure your are in the correct directory,  type "ls -F" and you should see 
the following files and directories:

Makefile    Testitems   domount.c   getopt.c    server*     tests.init
README      basic/      general/    runtests*   special/    tools/

The "server" script uses "getopt" and a source file of a public-domain 
version is included in the directory.  The makefile will compile it for you.

Changes may be required to the Makefile depending on the type of system
you are testing on and what version of NFS you are testing.  Change the 
COMPAT variable if you are running NFS3.2 to:

	COMPAT = -DNFS3_2

If you are running on a System V based system (SVR3) you will need to change:

	SYSTYPE=-DSVR3
	LIBS=-lrpc

If you are running Lachman NFS for System V Release 3, you should set the 
compatability variable to:

	COMPAT =  -DSVR3

Lachman NFS is based on NFS3.2, but you should not set NFS3_2.  That symbol 
is used only for vnode-based systems, not FSS-based systems.

If you are testing on a BSD based system SYSTYPE and LIBS should not be
set to anything.  Be sure and check the COMPAT variable if running 
release 3.2 of NFS. 

Two special targets are included in the Makefiles: copy and dist. The command 
"make copy DESTDIR="path"",  where "path" is the name of a directory, will 
cause the compiled tests to be copied to "path".  "make dist DESTDIR="path"", 
where "path" is the name of a directory,  will copy the test sources to 
"path".  DESTDIR must be specified on the make command line when making 
either of these targets.

Modifications may be required so the programs compile on your machine.  If 
that is so,  we would like to know what they are so that we can incorporate 
them into our distribution.  

When defaults are used,  the test programs expect /mnt to exist on the client 
and /server to exist on the server.    These defaults can be overridden at 
run time.  Read about how to run the testsuites for a description of how this 
is done.

NOTE:  When running any of the tests, you should save stdout and stderr
       output in a file for future reference.




How to run the Testsuites
-------------------------

There are two ways to run the tests: (1) use the server shell script or 
(2) mount, run the tests yourself,  and unmount.  We recommend you use the 
server script to run the tests.



The server script:

The server script executes the basic and general tests. (It runs the 
special tests only if use the -s option.)  It is set up to mount, 
run tests using the runtests program, and unmount.  It will attempt to unmount 
anything mounted on the mount point before attempting to mount the server file 
system. 

server uses the domount program to mount and unmount the test file systems.  
Since mount can only be executed by root,  domount must have root permission.  
The Makefile will attempt to setuid the domount program to root.  The server 
script can be run as a nonprivileged user. Alternately, you may login as root 
before you run server.



server [-a|-b|-g|-s] [-|-f|-t|-n] [-o mnt_options] [-p server_path] [-m mntpoint] server_name


-a|-b|-g|-s - will be passed on to the runtests scripts.  This argument is
	      optional.  The default is read from the initialization file,
	      tests.init.
	      This argument selects which tests to run:
		-a	run basic and general tests
		-b	run basic tests only
		-g	run general tests only
		-s	run special tests only
-f|-t|-n    - will be passed on to the runtests scripts.  This argument is
	      optional.  The default is read from the initialization file,
	      tests.init.
mnt_options - will be passed on to the mount command. This argument is
	      optional.  The default is read from the initialization file,
	      tests.init.
server_path - specifies a directory on the server to mount.  This argument
	      is optional.  The default is read from the initialization file,
	      tests.init.
mntpoint    - specifies a mount point on your client. This argument is
	      optional.  The default is read from the initialization file,
	      tests.init.
server_name - the server you want to exercise.  This is the only required 
	      argument. 

The test programs create a sub-directory in the mntpoint directory with the 
name 'hostname'.test (where 'hostname' is the name of the machine on which 
you run the tests).  This name can not be overridden if you use the server 
script although it can be if you use runtests directly.  

Example:  (the client machine is eddie)

eddie% server -o hard,intr,rw slartibartfarst
Start tests on path /mnt/eddie.test [y/n]? y
<output from tests>
         :
         :
All tests completed
eddie%

See the script for more details.

 

Run tests yourself:

There is a runtest script in the highest level directory (the master runtests) 
which uses tests.init to set up the test environment and then executes runtest 
scripts in the basic, general,  and/or special sub-directories. 


 runtests [-a|-b|-g|-s] [-f|-n|-t] [test-directory]


-a	       - Run the basic and general tests.  This is the default.
-b	       - Run the basic tests.
-g	       - Run the general tests. 
-s	       - Run the special tests.
-f	       - Set parameters for a quick functional test. This is the 
	         default.  It applies only to basic tests.
-n             - Suppress directory operations (mkdir and rmdir) on the 
		 test-directory.  See descriptions of basic tests for more
		 details.  
-t	       - Run full-length test with running time statistics. It only 
          	 applies to basic tests. You will want to rerun with "-t" after 
		 all the "-f" (default option) tests run successfully.


test-directory - The name of test directory that the test programs create 
		 on the client.   runtests executes the basic tests in place 
		 and they work on the test directory.  The general tests are 
		 copied over to the test directory and executed there.  When 
		 the -n flag is used, the test directory is assumed to already 
		 exist.

		 The default test-directory is /mnt/'hostname'.test (where 
		 'hostname' is the name of the machine on which you are 
		 running the tests). There are three ways to override the 
		 default test directory name.  One it to put the 
		 test_directory on the command line.  Another way is to set 
		 the environment variable NFSTESTDIR equal to the directory 
		 name.  The command line method overrides setting the 
		 environment variable.  The third way can only be used
		 for the tests in the basic sub-directory.  There you
		 can set the TESTDIR variable in tests.h.  The command
		 line and environment variable both override this
		 method.

Running the tests without mounting your NFS server on /mnt will run the tests 
locally (if /mnt is local disk).  We recommend that you do this once to make 
sure the testsuites run properly before you use them to test NFS.

The runtests in sub-directories: basic, general, and special,  may be invoked 
with the same arguments as the master runtests if you wish to run each suite 
separately.




How to run the Testsuites at Connectathon
-----------------------------------------


The tests should be run in the following order:  basic,  general, and special.
The basic tests should be passed completely before other tests are attempted.

The NFS Test Suite should be run in three phases:

Phase 1 - Run test programs locally.

Phase 2 - Run the tests against a Sun.  Run them on your machine using the
          Sun as the server and then run them on the Sun using your machine
          as the server.

Phase 3 - NxN Testing.  Run the tests on your machine using every other
	  machine as a server,  one at a time.  After the tests are 
	  successfully completed using a particular server,  log that
	  with the electronic board software provided. Check the electronic
	  board to make sure that the tests run successfully on 
	  every other machine that uses your machine as a server.


Test Descriptions
-----------------

System and library calls that are used by the testsuites are included in paren-
theses.  Look at the source if you are interested in how time statistics are 
recorded since that is not included in this description.




- BASIC TESTS:   

Many of the programs listed below have optional calling parameters that can be 
used to override existing parameters.  These are not used at this time so they 
are not described.