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. For a loopback setup with a mounted filesystem, you could do something like: sh local.sh ../utils/lconf --reformat local.xml 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. 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: 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 The "--node " 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. 2. runregression-net.sh and runregression-brw.sh 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 .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] .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.