-A variety of tests can be run or environments set up.
+1. How to build .xml configs:
+The various .xml configs in the tests/ directory are built by running the
+corresponding .sh script. The .sh script runs a series of lmc (Lustre make
+config) commands in order to build up an XML file. It is much easier to
+simply edit a .sh script and rebuild your XML config file than trying to
+edit the XML directly.
-1. runregression-net
+For a loopback setup with a mounted filesystem, you could do something like:
-Usage on server:
-llsetup.sh marcus-echo-server.cfg
+ sh local.sh
+ ../utils/lconf --reformat local.xml
-with marcus-echo-server.cfg:
+This will configure an MDS, an OBD/OST, and a filesystem client all running
+on the same system and communicating over the TCP loopback interface. If
+the --reformat option is given, then the OST and MDS devices will be
+formatted. This is required the first time you set up the system, or if
+you think you have corrupted the filesystems after you hit a bug.
-NETWORK=elan
-LOCALHOST=4
-SERVER=4
-SETUP_OST=y
-OSTTYPE=obdecho
+A more complex configuration, using a separate host for each of the MDS,
+OBD/OST, and filesystem client functions is in uml.sh. It configures 3
+systems, and the OST system (uml2) serves up multiple OST devices, and
+the client accesses these via a logical object volume (LOV) driver (which
+essentially stripes both of the OST devices into a single storage device.
+This configuration could be run on any 3 systems with the following commands:
-Usage on client:
-runregression-net marcus-echo-client.cfg
+ sh uml.sh
+ system1# ../utils/lconf --reformat --node uml1 uml.xml
+ system2# ../utils/lconf --reformat --node uml2 uml.xml
+ system3# ../utils/lconf --node uml3 uml.xml
-with marcus-echo-client.cfg:
+The "--node <name>" parameter tells lconf to use the configuration for
+the node "name" in the XML configuration file. If the hostnames were
+already "uml1", "uml2", and "uml3", then the "--node" parameter would
+not need to be given. The internals of lconf and portals handle the
+configuration details for setting up netowrking.
-NETWORK=elan
-LOCALHOST=5
-SERVER=4
-SETUP_OSC=y
+2. runregression-net.sh and runregression-brw.sh
-If things are allright it goes through all the tests single threaded,
-multithreaded, getattr and brw.
+This test performs raw block and attribute requests against a real or
+"null" OST device. It is useful for generating isolated load on the
+OST device, while avoiding the need to run tests through the filesystem.
+This can be useful for testing the network part of Lustre in isolation,
+or doing RPC and bulk I/O performance tests against an OST.
+If things are alright it goes through a series of tests single threaded,
+multithreaded, using getattr and brw (both read and write, with single
+page and vector I/O, doing basic data checking of each page).
+You can create a simple echo client by running the "llecho.sh" to
+run the tests locally (over TCP loopback), or edit llecho.sh to
+specify the SERVER and CLIENT names. You would then set up as normal:
+
+ # if you are using a remote server, first run:
+ server# ../utils/lconf echo.xml
+
+Configure the client (or if you are running a single system only):
+
+ client# ../utils/lconf echo.xml
+ client# sh runregression-net.sh
+
+3. runtests
+
+The runtests script does a series of simple file-based tests using a
+filesystem. You need to have an XML file as appropriate for your setup
+(one or more hosts, including an MDS, one or more OSTs, and a mountpoint).
+If the MDS and/or OST is on a remote machine, configure them first:
+
+ ../utils/lconf --reformat <conf>.xml
+
+On the client machine, the runtests script needs the XML configuration
+file as a command-line parameter, as it mounts and unmounts the filesystem
+several times during the test in order to verify that the data is still
+there as expected (ensures that it makes it to disk instead of just into
+the filesystem cache). If you are running on only a single machine, you
+can just use runtests directly. If this is only a client machine, the
+--reformat parameter is not needed (it will not do anything).
+
+ sh runtests [--reformat] <conf>.xml
+
+This creates a few simple files and directories first, and then untars
+a copy of the /etc filesystem into the Lustre filesystem. It then does
+data verification both before and after the filesystem is remounted, and
+finally deletes all of the files and verifies that the amount of space
+left in the filesystem is (nearly) the same as it was before the test.
git://git.whamcloud.com / fs / lustre-release.git / blobdiff