This section briefly describes the usage of the run tools provided with the SPEC System File Server (SFS) Release 3.0 suite. These tools provide both a novice mode (query driven) and a advanced mode (menu driven) interface that provide the user with helpful scripts that can set up the environment, set various benchmark parameters, compile the benchmark, conduct benchmark validation, execute the benchmark, view results from a run and archive the results. The results obtained from multiple data points within a run are also collected in a form amenable for ease of use with other result formatting tools. These tools are used on the primary load generator (Prime-Client) for benchmark setup and control as well as on the rest of the NFS load generators (clients) to assist in compiling the programs. While not required to run the benchmark, the SFS tools can facilitate the "quick" running of the benchmark for tuning various components of the system and results reporting. This section does not cover the complete Client-Server environment setup in detail. It touches only the portions currently handled by the tools. For information on how to set up and run the SFS suite the reader is advised to refer to the section on running SFS above.
The SFS Benchmark uses the UNIX "Makefile" structure (similar to other SPEC Suites) to build tools, compile the benchmark source into executables, and to clean directories of all executables. If you are familiar with other SPEC suites, navigating around SFS should be very similar. It is important to note that unlike other SPEC benchmarks, SPECsfs's validation and execution functions are built into the sfs_mgr script supplied with the benchmark. This script is used by the menu tools when validate or run targets are chosen. The following is a quick overview of the benchmark's directory structure. Please note that $SPEC is the path in the file system at which the benchmark is loaded.
Benchmark tools
The benchmark tools located in the $SPEC/benchspec/162.nfsv2/src directory. These
tools must be built (as described in the next section) before they can
be used. During the tools build, the executables are transferred to the
$SPEC/benchspec/162.nfsv2/bin directory.
Makefile Wrappers (M.<vendor>)
The Makefile wrappers are located in the $SPEC/benchspec/162.nfsv2/M.<vendor>
directory. The Makefile wrappers contain specific vendor compiler
options and flags.
Command Wrappers (C.<vendor>)
The Command wrappers are located in the $SPEC/benchspec/162.nfsv2/ C.<vendor.>)
directory. The Command Wrappers contain the vendor specific command
paths and commands for the remote utilities.
SPECsfs source
The benchmark source programs are located in the $SPEC/benchspec/162.nfsv2/src directory.
SPECsfs executables and scripts
Once SPECsfs is compiled, the resultant executables, along with copies
of the necessary scripts, are moved to the $SPEC/benchspec/162.nfsv2/result directory. This
directory is also known as $RESULTDIR.
SFS_RC files
Both the SFS default and user modified _rc files are located in the
$SPEC/benchspec/162.nfsv2/result directory.
These files contain the parameter values to be used by the SFS manager
(sfs_mgr) script as well as the tools driving the various menus.
After extracting the SPECsfs suite from the CD, change directory into the uppermost SPEC directory (SPEC home directory). The user's home environment can be initialized by executing:
For C-shell users: "source sfsenv" For Bourne or Korn shell users: ". ./sfsenv"
By executing this command, the SPEC environment variables SPEC, BENCH, RESULTDIR, TESTSRESULTS, etc. are all defined. The SPEC home directory can now be referenced as $SPEC. After setting up the SPEC home environment, the tools used by all the menus can be created by the following command:
make bindir
Once the make command completes, the runsfs script can be used to complete the installation process, to run the benchmark and to view or archive the results. The runsfs script will initially check to see if the sfsenv script has been executed. If it has not, it will execute it. It is important to note that if runsfs executes the script, upon exiting the runsfs script, environment variables will no longer be set. Additionally, the script will check if the bindir directory has been created. If it does not exist, it will create it.
The SPECsfs tools consist of a series of scripts that help the user in the installation, configuration, and execution of the benchmark. To invoke these tools, the user should run the runsfs script in the $SPEC directory. If the user has not yet executed the sfsenv script or created the tools, this script will execute them. The user will initially be prompted for the clients appropriate vendor type.
Example of Vendor Type Prompt
The benchmark has been ported to the following vendor/OS list:
att compaq dec_unix dgc
hpux10 hpux11 ibm ingr
Linux moto sgi sni
solaris2 sunos4 unicos unisys
unixware vendor xpg4.2 freebsd
Please enter your vendor type from the above list or press Return:
dec_unix
The default command file is being set to C.dec_unix .
Executing the C.dec_unix file...
Following the users response, the associated Makefile wrapper and Command wrapper are selected as the default wrappers. If the user wants to skip this step and go directly to the main SFS tools area, they may execute the run_sfs script in the $SPEC/benchspec/162.nfsv2 directory. In this case, the generic Makefile wrapper and Command wrapper (M.vendor and C.vendor) files will be set as the default wrappers. The user is then prompted if they want to use the Novice User Mode (query driven) or the Advanced User Mode (menu driven). The Novice User Mode is the default session type. This is intended to walk the new user through a benchmark setup, compilation, and execution as well as easily displaying benchmark results. For those familiar with the benchmark's setup and execution, Advanced Mode is preferred.
Example of Preferred Session Type Prompt
SPEC SFS tools may be run in one of two modes
- Novice mode ( query driven )
- Advanced mode ( menu driven )
Do you want to run in Advanced mode or Novice mode (a/n(default) )?
The following selection will summarize the Novice Mode user tools. The Novice Tools assumes that the user is unfamiliar with the SPECsfs environment. The user is led through the test configuration and execution process via a question and answer session. The tools initially help the user setup the client's environment/compiler variables via M.vendor and C.vendor files. After setting up the user environment, the tools allow the user to compile the benchmark, modify the test parameters in the _rc file, run a test, view the results of a test or archive test results. Please note that the Novice Tools contain a subset of the functions contained in the Advanced Tools. The following section is intended to present the various functions available to the user via the Novice User Tools. The following examples show the querying structure of the Novice Mode Tools.
The first series of questions the user must answer deal with selecting the appropriate wrapper files for the particular client/server environment. There are two types of wrapper files, Makefile wrappers and Command Wrappers. The Makefile wrappers contain specific vendor compiler options and flags needed during the compilation process. The Command wrappers contain the vendor specific command paths and commands needed for the remote utilities. This is asked initially, since prior to many of the functions (i.e. benchmark compilation) it is important for the user to select the appropriate wrappers.
Makefile wrapper selection and compilation of the benchmark programs need to be done on all clients including the Prime-Client after initially installing SPECsfs on the load generators. The user is initially asked if they want to use the default M.vendor file or a different makefile wrapper file.
Do you want to use the default M.vendor file - M.dec_unix
( (y)es, (n)o )?
The default M.vendor file is associated with the client vendor type previously selected. For example, in the previous example, the M.dec_unix file would be selected since a Digital client vendor type was selected. If the default M.vendor file is selected, the user is given the option of modifying its contents. If the user would like to modify the file, the tools will display the contents of the default M.vendor file.
Do you want to use the default M.vendor file - M.dec_unix ( (y)es, (n)o )? y Do you want to edit the M.dec_unix file ((y)es, (n)o)? y Checking Wrapper file....... To Continue Please Press The <RETURN> key: Current Settings 1) MACHID -> dec_osf 2) C COMPILER -> /bin/cc 3) C OPTIONS -> -O 4) C FLAGS -> 5) LOAD FLAGS -> 6) EXTRA CFLAGS -> -DUSE_POSIX_SIGNALS 7) EXTRA LDFLAGS -> 8) LIBS -> -lm 9) EXTRA LIBS -> 10) OSTYPE -> -DOSF1 11) RESVPORT_MOUNT -> 12) Shell Escape 13) Save Wrapper File 14) Return to Main Menu Select Setting :
If the user would like to use a different M.vendor file, the tool will display a list of all vendor specific makefile wrappers currently available on the CD. The user can look into any vendor wrapper file and modify it suitably and store the file on the system under the same or a different name and use it to compile the benchmark programs. These wrappers are all named with a "M." prefix.
Do you want to use the default M.vendor file - M.dec_unix
( (y)es, (n)o )? n
The current M.vendor file is: M.dec_unix
--------------------------------------
The following is a list of the available M.vendor wrapper files.
----------------------------------------------------------------
att compaq dec_unix dgc freebsd
hpux10 hpux11 ibm ingr linux
moto sgi sni solaris2
sunos4 unicos unisys unixware
vendor xpg4.2
Enter only the VENDOR part of M.vendor file name
Hit Return if using the current M.dec_unix: hpux11
Checking Wrapper file .......
To Continue Please Press The <RETURN> key:
Current Settings
1) MACHID -> hp
2) C COMPILER -> /opt/ansic/bin/cc
3) C OPTIONS -> -O -Ae
4) C FLAGS -> -D_HPUX_SOURCE
5) LOAD FLAGS ->
6) EXTRA CFLAGS -> -DHAS_GETHOSTNAME -DDNO_T_TYPES
7) EXTRA LDFLAGS ->
8) LIBS -> -lm
9) EXTRA LIBS ->
10) OSTYPE -> -DHPUX
11) RESVPORT_MOUNT ->
12) Shell Escape
13) Save Wrapper File
14) Return to Main Menu
Select Setting :
Note that each item in the above menu is user definable and it is good practice to "save" the wrapper file under a different name if any parameter is modified.
The user is then prompted for the appropriate command wrappers (C.vendor) in order to define the appropriate commands and command paths. Users are given the choice of the default C.vendor file or a different command wrapper file.
Do you want to use the default C.vendor file - C.dec_unix ( (y)es, (n)o )?
Similar to the M.vendor files, the default C.vendor file is associated with the client vendor type previously selected. If the user selects the default C.vendor file, they will be given the option to modify the contents of this file. If they would like to modify the file, the tools will display the contents of the c.vendor file.
Do you want to use the default C.vendor command file - C.dec_unix ( (y)es, (n)o, (p)revious )? y Do you want to edit the file ((y)es, (n)o, (p)revious)? y Current C.vendor Parameter Settings 1) PASSWD_FILE -> /etc/passwd 2) FSTAB_FILE -> /etc/fstab 3) GROUP_FILE -> /etc/group 4) HOSTNAME_CMD -> hostname 5) RSH_CMD -> rsh 6) SHELL -> /bin/sh 7) AWK_CMD -> awk 8) PS_CMD -> ps ax 9) ECHO -> echo 10) NONL -> 11) Shell Escape 12) Save C.vendor File 13) Return to Main Menu Select Setting :
If the user would like to use a different C.vendor file, the tool will display a list of all vendor specific command wrappers currently available on the CD. The user can look into any vendor wrapper file and modify it suitably and store the file on the system under the same or a different name and use it to compile the benchmark programs. These wrappers are all named with a "C." prefix.
Do you want to use the default C.vendor command file - C.dec_unix ( (y)es, (n)o, (p)revious )? n The following is a list of the available C.vendor wrapper files. ---------------------------------------------------------------- C.sgi C.hpux10 C.hpux11 C.sni C.dec_unix freebsd C.unixware C.vendor C.unicos C.solaris2 C.sunos4 C.intel C.hpux9 C.ibm C.linux C.att Enter only vendor part of M.vendor File name Hit Return if using C.dec_unix: Current C.vendor Parameter Settings 1) PASSWD_FILE -> /etc/passwd 2) FSTAB_FILE -> /etc/fstab 3) GROUP_FILE -> /etc/group 4) HOSTNAME_CMD -> hostname 5) RSH_CMD -> rsh 6) SHELL -> /bin/sh 7) AWK_CMD -> awk 8) PS_CMD -> ps ax 9) ECHO -> echo 10) NONL -> 11) Shell Escape 12) Save C.vendor File 13) Return to Main Menu Select Setting :
Note that each item in the above menu is user definable and it is good practice to "save" the wrapper file under a different name if any parameter is modified.
Once the environment setup is complete, the user enters the main execution loop. The main execution loop is:
Enter whether you want to (r)un, re(c)ompile, (e)dit an .rc file, (v)iew results, (a)rchive results, (p)revious question, (q)uit ...
The user is now given the option to: run the benchmark: compile (or recompile) the benchmark, edit the _rc file, view existing test results, archive test results, or quit the test.
If the user selects the run option, the tools will check if the benchmark has been compiled previously. If it has not yet been compiled, the tools will initially compile the benchmark.
Enter whether you want to (r)un, re(c)ompile, (e)dit an .rc file,
(v)iew results, (a)rchive results, (p)revious question, (q)uit ... r
Executable not found ... compiling benchmark ...
The current M.vendor file is: M.dec_unix
--------------------------------------
The following is a list of the available M.vendor wrapper files.
----------------------------------------------------------------
att compaq dec_unix dgc
hpux10 hpux11 ibm ingr
linux moto sgi sni
solaris2 sunos4 unicos unisys
unixware vendor xpg4.2
Enter only the VENDOR part of M.vendor file name
Hit Return if using the current M.dec_unix:
chmod +x run_sfs
`librpclib.a' is up to date.
:
:
:
./sfs_suchown sfs sfs3
... Done
To Continue Please Press The <RETURN> key:
Once there is a benchmark executable available, the user will then be prompted for the appropriate _rc file. The user is then allowed to select the appropriate _rc file. The user may select from any existing _rc files or may create a new file.
List of Available RC Files that End with _rc - Latest First --------------------------------------------------------------------- don_rc short_v2_rao_2dsk_rc stephen_tcp_v3_rc test_tcp_2_rc augie_tcp_3_rc test_tcp_v2_rc test_tcp_v3_rc test_udp_2_rc debug_tcp_2_rc full_tcp_v2_rc full_tcp_v3_rc full_udp_v2_rc full_udp_v3_rc remote_rc sfs_rc short_rc short_tcp_rc short_udp_v3_rc temp_rc test_new_rc Enter your RC File name Hit Return if using original sfs_rc templates with default values. This will prompt you for new parameter values. Else pick up an existing "_rc" file from above list:
If the user selects the option to create a new _rc file using the sfs_rc file, they will be prompted for the appropriate parameter values
Load information: ----------------- Current value of LOAD Inital/Series: To retain this value type <RETURN> For null value type <space> & <RETURN> The requested load is the total load applied to the server. Example of a full curve: 100 200 300 400 500 600 700 800 900 100. Enter new LOAD Initial/Series value : 100 200 300 400 500 NFS Version: ------------ Current value of NFS Version: To retain this value type <RETURN> For null value type <space> & <RETURN> The NFS version parameter: NFS V2 - "" or 2 (default), NFS V3 - 3 Enter new NFS Version value : Protocol: --------- Current value of Use TCP: To retain this value type <RETURN> For null value type <space> & <RETURN> Network Transport parameter: NFS/UDP - "" or 0 (default), NFS/TCP - 1. Enter new Use TCP value : Clients: -------- Current value of Clients: To retain this value type <RETURN> For null value type <space> & <RETURN> Example of client listing: client1 client2 client3 client4 Enter new Clients value : client1 client2 Mount Points: ------------- To retain this value type <RETURN> For null value type <space> & <RETURN> Mount point can either be a listing of mount points or a name of a file in the $WORK_DIR directory. Examples: 1) listing: server:/mnt1 server:/mnt2 server:/mnt3 server:/mnt4 2) mount file (each line represents one client's mount points): client1 server:/mnt1 server:/mnt2 server:/mnt3 server:/mnt4 Enter new Mount Points value : svr:/mnt1 svr:/mnt2 svr:/mnt3 svr:/mnt4 Load Generating Processes: -------------------------- To retain this value type <RETURN> For null value type <space> & <RETURN> The Load Generating Processes (PROCS) range should be greater than or equal to 8. Enter new Number of Load Generating Processes value : 4 Saving the _rc file information ... New _rc file name: new_test_rc
Once the new file is generated or if the user opts to use an existing _rc file they will proceed to the execution of the benchmark. The user must supply the tools with a unique test suffix name that will be appended to all test files (sfsval, sfslog, sfsres, sfssum, sfsc*).
Enter suffix for log files, results summary etc (Do not exceed 3 chars if there is a 14 character limit): test1 Wed Jul 11 21:43:46 EDT 2001 Executing run 1 of 10 ... done Wed Jul 11 21:54:46 EDT 2001 Executing run 2 of 10 ... done Wed Jul 11 22:06:18 EDT 2001 Executing run 3 of 10 ... done Wed Jul 11 22:18:17 EDT 2001 Executing run 4 of 10 ... done Wed Jul 11 22:30:41 EDT 2001 Executing run 5 of 10 ... done Wed Jul 11 22:43:33 EDT 2001 Executing run 6 of 10 ... done Wed Jul 11 22:56:55 EDT 2001 Executing run 7 of 10 ... done Wed Jul 11 23:10:40 EDT 2001 Executing run 8 of 10 ... done Wed Jul 11 23:24:49 EDT 2001 Executing run 9 of 10 ... done Wed Jul 11 23:39:23 EDT 2001 Executing run 10 of 10 ... done
The SPECsfs benchmark run time parameters in existing _rc file can be specified by selecting edit option and following the sub-menu as shown here. Note that the CLIENTS, LOAD, MNT_POINTS, PROC parameters MUST be supplied in order to run the benchmark. When specifying these values it is important to remember these rules:
a. svr:/mnt1 svr:/mnt2 svr:/mnt3 svr:/mnt4
b. mount_point_file_name (each line represents the mount points for one
client. The mount_point_file_name looks like the following:
cl1 svr:/mnt1 svr:/mnt2 svr:/mnt3 svr:/mnt4
cl2 svr:/mnt5 svr:/mnt6 svr:/mnt7 svr:/mnt8
Warning: The _rc files may be hand edited, however, any error introduced into the file may cause the tool to abort.
Enter whether you want to (r)un, re(c)ompile, (e)dit an .rc file, (v)iew results, (a)rchive results, (p)revious question, (q)uit ... e List of Available RC Files that End with _rc - Latest First --------------------------------------------------------------------- don_test_rc stephen_rc rao_v2_tcp_rc sudhir_tcp_v3_rc augie_tcp_2_rc barry_tcp_3_rc test_tcp_v2_rc test_tcp_v3_rc test_udp_2_rc debug_tcp_2_rc full_tcp_v2_rc full_tcp_v3_rc full_udp_v2_rc full_udp_v3_rc remote_rc sfs_rc short_rc short_tcp_rc short_udp_v3_rc temp_rc Enter your RC File name Hit Return if using original sfs_rc templates with default values. This will prompt you for new parameter values. Else pick up an existing "_rc" file from above list: don_test_rc Current modifiable RC Parameter Settings (Page 1) All parameters except for LOAD are on a "per client" basis. 1) LOAD -> 100 200 300 400 500 2) BIOD_MAX_WRITES -> 2 3) BIOD_MAX_READS -> 2 4) NFS_VERSION -> 5) NUM_RUNS -> 1 6) INCR_LOAD -> 0 7) CLIENTS -> client1 client2 8) MNT_POINTS -> svr:/mnt1 svr:/mnt2 svr:/mnt3 svr:/mnt4 9) PROCS -> 4 10) TCP -> 11) Shell Escape 12) Continue to view additional modifiable parameters 13) Save RC File 14) Return to Main Menu Select Setting : 12 Additional modifiable RC Parameter Settings (Page 2) 1) PRIME_SLEEP -> 0 2) PRIME_MON_SCRIPT -> 3) DEBUG -> 4) DUMP -> 5) SFS_DIR -> /local_mnt2/spec/spec-sfs3.0/benchspec/162.nfsv2 6) WORK_DIR -> /local_mnt2/spec/spec-sfs3.0/benchspec/162.nfsv2 7) Shell Escape 8) Continue to view fixed parameters 9) Save RC File 10) Return to Main Menu Select Setting :
Once there are existing summary files, the user may view them within the SFS tools.
Enter whether you want to (r)un, re(c)ompile, (e)dit an .rc file, (v)iew results, (a)rchive results, (p)revious question, (q)uit ... v Current SUFFIX= List of Suffixes For Which Results Are Available: ----------------------------------------------------------- Augie_2disk Rao_v2_tcp_2dsk Dont_v3_tcp Enter suffix string for the results you wish to view: test_2disk Searching for Results file /local_mnt2/spec/spec-sfs3.0/benchspec/162.nfsv2/result/sfssum.Augie_2disk 200 200 3.5 60091 300 3 U 2028208 2 7 0 0 3.0 400 400 3.9 120054 300 3 U 4056052 2 7 0 0 3.0 600 598 4.3 179507 300 3 U 6084260 2 7 0 0 3.0 800 801 5.0 231226 288 3 U 8112104 2 7 0 0 3.0 1000 999 5.8 271714 272 3 U 10140312 2 7 0 0 3.0
The following selection will summarize the Advance Mode user tools. The user will be presented with the functions that the Advanced Mode Tools offer. The following example shows the Advanced More Main Menu structure.
Example of the Advanced Mode Main Menu
Main Menu : 162.V2 Benchmark 1) View/Change/Create M.vendor file 2) View/Change/Create C.vendor file 3) View/Change/Create RC file 4) Remote Client Setup Utilities 5) Clean SFS Source files 6) Start Compilation 7) Start Run 8) View Results 9) Archive Results 10) Shell Escape 11) Exit 162.V2 Benchmark Choice :
After initially installing SPECsfs on the load generators, the user must compile the benchmark on each of the load generators. Prior to compilation, it is important for the user to select the appropriate Makefile wrappers and Command Wrappers. The Makefile wrappers contain specific vendor compiler options and flags needed during the compilation process. The Command wrappers contain the vendor specific command paths and commands needed for the remote utilities. Wrapper file modification and compiling of the benchmark programs need to be done on all clients including the Prime-Client. The "Choice" of "1" in the above menu gives a listing of all the vendor specific makefile-wrappers currently available on the CD. The user can look into any vendor wrapper file and modify it suitably and store the file on the system under the same or a different name and use it to compile the benchmark programs. These wrappers are all named with a "M." prefix. For example, the linux vendor wrapper is named "M.linux".
Example of the M.vendor Wrapper Prompts
List of Available M.vendor wrapper Files ------------------------------------------ att compaq dec_unix dgc freebsd hpux10 hpux11 ibm ingr linux moto sgi sni solaris2 sunos4 unicos unisys unixware vendor xps4.2 Current M.vendor file is: M.linux Enter only vendor part of M.vendor File name. Hit Return if using M.linux : Checking Wrapper file ....... To Continue Please Press The <RETURN> key: Thank You! Current Settings 1) MACHID -> linux 2) C COMPILER -> /bin/cc 3) C OPTIONS -> -O 4) C FLAGS -> 5) LOAD FLAGS -> 6) EXTR CFLAGS -> 7) EXTR LDFLAGS -> 8) LIBS -> -lm 9) EXTRA LIBS -> 10) OSTYPE -> -DLinux 11) SETPGRP CALL -> 12) RESVPORT_MOUNT -> 13) Shell Escape 14) Save Wrapper File 15) Return to Main Menu Select Setting :
Each item in the above menu is user definable and it is good practice to "save" the wrapper file under a different name if any parameter is modified. After exiting this submenu, if the user has not yet compiled the benchmark or the user has modified the M.vendor file since the last compilation, the user is encouraged to select option 6, Start Compilation, of the main menu to compile the benchmark. Compilation must be done on each client, or on each location that is NFS mounted by a client, before the run is started. At the end of compilation, the tool sets root ownership on the sfs and sfs3 executables so that it can perform port binding to a privileged port as shown below, which may necessitate the typing of root password. If requested, please enter the password required by the su(1) command on your system. If you do not have the root password, hit RETURN and SPECsfs97_R1 will be installed without SUID root; you will need to chown it to root and chmod it to SUID by other means, e.g. asking your system administrator.
Example of the C.vendor Wrapper Prompts
The following is a list of the available C.vendor wrapper files. ---------------------------------------------------------------- C.sgi C.hpux10 C.hpux11 C.sni C.dec_unix C.freebsd C.unixware C.vendor C.unicos C.solaris2 C.sunos4 C.intel C.ibm C.att C.linux Enter only vendor part of M.vendor File name Hit Return if using C.linux: Current C.vendor Parameter Settings 1) PASSWD_FILE -> /etc/passwd 2) FSTAB_FILE -> /etc/fstab 3) GROUP_FILE -> /etc/group 4) HOSTNAME_CMD -> hostname 5) RSH_CMD -> rsh 6) SHELL -> /bin/sh 7) AWK_CMD -> awk 8) PS_CMD -> ps ax 9) ECHO -> echo 10) NONL -> 11) Shell Escape 12) Save C.vendor File 13) Return to Main Menu Select Setting :
Each item in the above menu is user definable and it is good practice to "save" the wrapper file under a different name if any parameter is modified.
The SPECsfs benchmark run time parameters can be specified by selecting option 3 of the main menu and following the sub-menu as shown here. Note that the CLIENTS, LOAD, MNT_POINTS, PROC parameters MUST be supplied in order to run the benchmark. When specifying these values it is important to remember these rules:
a. svr:/mnt1 svr:/mnt2 svr:/mnt3 svr:/mnt4
b. mount_point_file_name (each line represents the mount points for one
client. The mount_point_file_name looks like the following:
cl1 svr:/mnt1 svr:/mnt2 svr:/mnt3 svr:/mnt4
cl2 svr:/mnt5 svr:/mnt6 svr:/mnt7 svr:/mnt8
Warrning: The _rc files may be hand edited, however, any error introduced into the file may cause the tool to abort.
Example of Viewing the _rc file
List of Available RC Files That End With _rc Latest First ----------------------------------------------------------- sfs1_rc sfs2_rc sfs_rc Enter your RC File name Hit Return if using original sfs_rc templates with default values Else pick up an "_rc" file from above list: sfs1_rc Checking RC file ....... Current RC Parameter Settings (Page 1) Default values are in parentheses. 1) LOAD -> 100 200 300 400 500 2) BIOD_MAX_WRITES -> 2 3) BIOD_MAX_READS -> 2 4) NFS_VERSION -> 5) NUM_RUNS -> 1 6) INCR_LOAD -> 0 7) CLIENTS -> cl1 cl2 8) MNT_POINTS -> 9) PROCS -> 4 10) TCP -> svr:/mnt1 svr:/mnt2 svr:/mnt3 svr:/mnt4 11) Shell Escape 12) Continue to view additional modifiable parameters 13) Save RC File 14) Return to Main Menu Select Setting :
Example of the Modifying the Client Information
Current RC Parameter Settings (Page 1) Default values are in parentheses. 1) LOAD -> 100 200 300 400 500 2) BIOD_MAX_WRITES -> 2 3) BIOD_MAX_READS -> 2 4) NFS_VERSION -> 5) NUM_RUNS -> 1 6) INCR_LOAD -> 0 7) CLIENTS -> cl1 cl2 8) MNT_POINTS -> 9) PROCS -> 4 10) TCP -> svr:/mnt1 svr:/mnt2 svr:/mnt3 svr:/mnt4 11) Shell Escape 12) Continue to view additional modifiable parameters 13) Save RC File 14) Return to Main Menu Select Setting : 7 Clients: cl1 cl2 To retain this value type <RETURN> For null value type <space> & <RETURN> Enter new Clients value : mach1 mach2 Current RC Parameter Settings (Page 1) Default values are in parentheses. 1) LOAD -> 100 200 300 400 500 2) BIOD_MAX_WRITES -> 2 3) BIOD_MAX_READS -> 2 4) NFS_VERSION -> 5) NUM_RUNS -> 1 6) INCR_LOAD -> 0 7) CLIENTS -> mach1 mach2 8) MNT_POINTS -> 9) PROCS -> 4 10) TCP -> svr:/mnt1 svr:/mnt2 svr:/mnt3 svr:/mnt4 11) Shell Escape 12) Continue to view additional modifiable parameters 13) Save RC File 14) Return to Main Menu Select Setting :
If you want runsfs to establish your clients as SFS load generators, choose option 4, "Remote Client Setup Utilities", from the main menu.
Example of the Remote Client Setup Utility Submenu
Sub Menu : Remote Client Setup Utilities 1) Copy SFS source to Remote Client(s) 2) Shell Escape 3) Exit to Main Menu Choice :
You may select task 1 to perform the steps necessary to setup the Remote Client(s). The runsfs command will prompt for the vendor and the _rc file. The tool will offer to set up a spec user and prompt for "Y" or "N".
The prerequisites for running the SFS benchmark are prompted when runsfs command is used. They are listed here.
PREREQUISITES TO RUNNING THE 162.V2 BENCHMARK
The following prerequisite list should be checked before starting a benchmark run.
After the above prerequisites are satisfied, the SFS benchmark can be run by choosing option 7 from the main menu. The "Run" option prompt the user to validate the benchmark on the server. Validation must be done to prior to generating a valid SFS result. After the server passes validation, the menu reminds the user about newfsing the shared server file partitions to assure that all data files are written afresh on the server disks. Note: The runsfs script will not actually perform newfs's. You must escape the program and perform them manually at this time. If a run fails for some reason, the tool will advise you of this and possibly direct you where you might be able to find more information. See Section 11, "General Debug Information" for more about tracking down problems with SPECsfs. Hint: The most common problem is usually that file server filesystems are not being correctly mounted on the clients. Reminder: The benchmark "run" may take many hours to complete depending upon how many data points were requested. Also, some failures may take more than an hour to manifest themselves.
Example of a Benchmark Run
Assume that the user has already selected the M.vendor file, the C.vendor file, compiled the benchmark, and selected the _rc file.
Main Menu : 162.V2 Benchmark 1) View/Change/Create M.vendor file 2) View/Change/Create C.vendor file 3) View/Change/Create RC file 4) Remote Client Setup Utilities 5) Clean SFS Source files 6) Start Compilation 7) Start Run 8) View Results 9) Archive Results 10) Shell Escape 11) Exit 162.V2 Benchmark Choice : 7 Using sfs1_rc as the RC file Enter suffix for log files, results summary etc (Do not exceed 3 chars if there is a 14 character limit): k7 The Results from this run will be stored in /spec_sfs/benchspec/162.nfsv2/result/sfssum.k7 >> Do you want to run the VALIDATION test ? Answer y or n (default is y): y >>>>> STARTED SFS VALIDATION ON 07/11/2001 AT 20:42:46 <<<<< Validation completed >> Prior to running SFS for valid publication data, all targeted >> file systems on the server are required to be cleaned (newfs'ed). Have all targeted server file systems been NEWFS'ed ? Answer y or n (default is y): >>>>> STARTED SFS RUNS ON 07/11/01 AT 20:42:47 <<<<< Wed Jul 11 20:43:46 EDT 2001 Executing run 1 of 10 ... done Wed Jul 11 20:54:46 EDT 2001 Executing run 2 of 10 ... done Wed Jul 11 21:06:18 EDT 2001 Executing run 3 of 10 ... done Wed Jul 11 21:18:17 EDT 2001 Executing run 4 of 10 ... done Wed Jul 11 21:30:41 EDT 2001 Executing run 5 of 10 ... done Wed Jul 11 21:43:33 EDT 2001 Executing run 6 of 10 ... done Wed Jul 11 21:56:55 EDT 2001 Executing run 7 of 10 ... done Wed Jul 11 22:10:40 EDT 2001 Executing run 8 of 10 ... done Wed Jul 11 22:24:49 EDT 2001 Executing run 9 of 10 ... done Wed Jul 11 22:39:23 EDT 2001 Executing run 10 of 10 ... done The results & log files are in /users/sfs/spec-sfs3.0/benchspec/162.nfsv2/result To Continue Please Press The "RETURN" key:
Once there are existing summary files, the user may view them within the SFS tools.
Example of the Viewing Results
Current SUFFIX=k7 List of Suffixes For Which Results Are Available: ------------------------------------------------- k1 k2 k3 k4 k5 k6 k7 Enter suffix string for the results you wish to view: Press <RETURN> for k2: Searching for Results file /spec_sfs/spec-sfs3.0/benchspec/162.nfsv2/result/sfssum.k2 ... Enter suffix string for the results you wish to view: test_2disk Searching for Results file /spec_sfs/spec-sfs3.0/benchspec/162.nfsv2/result/sfssum.k2 200 200 3.5 60091 300 3 U 2028208 2 7 0 0 3.0 400 400 3.9 120054 300 3 U 4056052 2 7 0 0 3.0 600 598 4.3 179507 300 3 U 6084260 2 7 0 0 3.0 800 801 5.0 231226 288 3 U 8112104 2 7 0 0 3.0 1000 999 5.8 271714 272 3 U 10140312 2 7 0 0 3.0
The user interfaces explained above may not be able to help the user much in case of problems, especially those related to the network layers. Many problems may be eliminated if the user follows the prerequisites mentioned in the "PREREQUISITIES" menu. (A list of key prerequisites is displayed when first running runsfs) Other problems related to NFS or RPC operations should be handled outside the tools. More experienced users may find it more effective to interact more directly with the benchmark as described below.
For the more experienced user, the SPECsfs benchmark may be run without using the above-described tools. The following section is a quick summary of this process.
As with the tools, the user must first set up the SPEC environmental variables as indicated at the beginning of this section.
cd to the top level spec directory
source sfsenv or . ./sfsenv
The user must then move to the parent directory to compile the benchmark.
cd $SPEC/benchspec/162.nfsv2
The various vendor wrapper files will be found in this directory. To compile, you need to identify the appropriate vendor wrapper for the load generator system(s) being used. An ls M.* will list the available vendor wrappers. The programs need to be compiled using one of the given wrapper files, (example: M.att) or one that was created using the given M.<vendor> wrapper files. The command to compile the source programs is:
make -f M.wrappers/M.<vendor>
The root password may be required in order to set the setuid bit. The executables and other necessary files are copied onto the $SPEC/benchspec/162.nfsv2/result directory by this command.
The benchmark can then be run from this directory using the following command.
sfs_mgr -r <sfs_rc file> -s <suffix>
The -s option in the command line is required only when a tag is needed to identify the SFS run log files and the result files. Use of tags to differentiate results is highly recommended. Note that on 14 character name file systems, the tag should not be more than 3 characters long. Long name file systems are not so constrained. The _rc file (which may have any name ending in _rc) supplies the parameters to the benchmark.
To obtain a valid SFS run, the user should run the validation suite. One of the following two commands should be used. Note the -v option indicates the level of validation to be done. In this example level 2 validation will be done.
sfs_mgr -v 2 -r <sfs_rc file> -s <suffix>
or
sfs_mgr -v 2 -r <sfs_rc file>
The SFS 3.0 Release includes a tool for generating benchmark results in a format that can be submitted by email to the SFS results processing facility at SPEC, which will automatically process these results and distribute them to the SFS subcommittee for review. This section describes how you can use this tool to generate a file for each result that you wish to submit for review by SPEC. The submission tool and associated files are located in the submit_tools subdirectory under the spec-sfs3.0 directory. The tool is called generate and the associated files are as follows:
In order to produce a submission file using generate, you must have the _rc file and the sfssum._ file from your benchmark run. You can optionally create a "static information file" similar to the one provided with the tools (example_info) that captures all of the unchanging information about your company, product and testbed configuration. This file is optional because generate can be run in one of two modes: one in which it reads the static information file and another in which it prompts you for all of the information that is present in this information file. Using a file as input is particularly advantageous if you are submitting multiple results.
The tool is invoked simply by executing the generate program. The initial menu offers three choices:
The only difference between options [1] and [2] is that in the latter, the program prompts you for the location of the static information file and reads it, whereas in the former, the program takes you through an extensive list of self-explanatory questions to obtain the same information. In either option [1] or [2], once the "static information" has been gathered, the program continues by asking you for the location of the _rc and sfssum._ files. Once it has read these files, it prompts you for information about the clients listed in the _rc file. You are asked to choose the type of the client from the list of types that you have provided earlier either through the static information file or in the information gathering phase of option [1] above. You are also asked to specify the network that each client is attached to - again, you must specify this using the same terminology you used earlier in specifying the testbed configuration. Finally, it asks you for any optional comments about the client(s). Once all the listed clients are processed, the program prompts you for a name for the submission file and generates the submission file. A sample output file is provided - example.out.
In general, it is not recommended that you edit the submission file produced by the generate tool. However, depending on the way you have specified the _rc file for your benchmark run, it is possible that the specification of the load generators in the final submission file is either misformatted or redundant. Therefore, it is recommended that you view the submission file using an editor and correct any such errors/redundancies. The sample output file provided with the SFS 3.0 distribution was produced by generate using the example_rc file. This file results in two load generator descriptor blocks in example.out, both of which are identical except for the tb_lg_number field, which denotes the load generator number. These two blocks can be combined by listing both load generator numbers in a single block, as in example.submit.
Once you have generated a submission file as described in previous sections, you can email this file to subsfs97@spec.org. Upon receipt, the SPEC results processing facility will parse the submission file and validate the formats. If the check passes, an email reply is returned to the sender including a submission number assigned to the result. This submission number is used to track the result during the review and publishing process. If there are any formatting errors, the parser will respond with a failure message indicating where in the file the parsing failed. You may then either correct the error and resubmit or contact the SPEC office for further assistance.