lustre/tests/README

   1 1. How to build .xml configs:
   2 The various .xml configs in the tests/ directory are built by running the
   3 corresponding .sh script.  The .sh script runs a series of lmc (Lustre make
   4 config) commands in order to build up an XML file.  It is much easier to
   5 simply edit a .sh script and rebuild your XML config file than trying to
   6 edit the XML directly.
   7
   8 For a loopback setup with a mounted filesystem, you could do something like:
   9
  10    sh local.sh
  11    ../utils/lconf --reformat local.xml
  12
  13 This will configure an MDS, an OBD/OST, and a filesystem client all running
  14 on the same system and communicating over the TCP loopback interface.  If
  15 the --reformat option is given, then the OST and MDS devices will be
  16 formatted.  This is required the first time you set up the system, or if
  17 you think you have corrupted the filesystems after you hit a bug.
  18
  19 A more complex configuration, using a separate host for each of the MDS,
  20 OBD/OST, and filesystem client functions is in uml.sh.  It configures 3
  21 systems, and the OST system (uml2) serves up multiple OST devices, and
  22 the client accesses these via a logical object volume (LOV) driver (which
  23 essentially stripes both of the OST devices into a single storage device.
  24
  25 This configuration could be run on any 3 systems with the following commands:
  26
  27     sh uml.sh
  28     system1# ../utils/lconf --reformat --node uml1 uml.xml
  29     system2# ../utils/lconf --reformat --node uml2 uml.xml
  30     system3# ../utils/lconf --node uml3 uml.xml
  31
  32 The "--node <name>" parameter tells lconf to use the configuration for
  33 the node "name" in the XML configuration file.  If the hostnames were
  34 already "uml1", "uml2", and "uml3", then the "--node" parameter would
  35 not need to be given.  The internals of lconf and portals handle the
  36 configuration details for setting up netowrking.
  37
  38 2. runregression-net.sh and runregression-brw.sh
  39
  40 This test performs raw block and attribute requests against a real or
  41 "null" OST device.  It is useful for generating isolated load on the
  42 OST device, while avoiding the need to run tests through the filesystem.
  43 This can be useful for testing the network part of Lustre in isolation,
  44 or doing RPC and bulk I/O performance tests against an OST.
  45
  46 If things are alright it goes through a series of tests single threaded,
  47 multithreaded, using getattr and brw (both read and write, with single
  48 page and vector I/O, doing basic data checking of each page).
  49
  50 You can create a simple echo client by running the "llecho.sh" to
  51 run the tests locally (over TCP loopback), or edit llecho.sh to
  52 specify the SERVER and CLIENT names.  You would then set up as normal:
  53
  54     # if you are using a remote server, first run:
  55     server# ../utils/lconf echo.xml
  56
  57 Configure the client (or if you are running a single system only):
  58
  59     client# ../utils/lconf echo.xml
  60     client# sh runregression-net.sh
  61
  62 3. runtests
  63
  64 The runtests script does a series of simple file-based tests using a
  65 filesystem.  You need to have an XML file as appropriate for your setup
  66 (one or more hosts, including an MDS, one or more OSTs, and a mountpoint).
  67 If the MDS and/or OST is on a remote machine, configure them first:
  68
  69     ../utils/lconf --reformat <conf>.xml
  70
  71 On the client machine, the runtests script needs the XML configuration
  72 file as a command-line parameter, as it mounts and unmounts the filesystem
  73 several times during the test in order to verify that the data is still
  74 there as expected (ensures that it makes it to disk instead of just into
  75 the filesystem cache).  If you are running on only a single machine, you
  76 can just use runtests directly.  If this is only a client machine, the
  77 --reformat parameter is not needed (it will not do anything).
  78
  79     sh runtests [--reformat] <conf>.xml
  80
  81 This creates a few simple files and directories first, and then untars
  82 a copy of the /etc filesystem into the Lustre filesystem.  It then does
  83 data verification both before and after the filesystem is remounted, and
  84 finally deletes all of the files and verifies that the amount of space
  85 left in the filesystem is (nearly) the same as it was before the test.