OCFS2 Testing Cookbook

Introduction

This document lists the steps needed to download, build, install and run ocfs2-test.

Note: The tests need to be built and installed and will not execute from the source tree.

Tests

The list of tests can be reviewed here.

The cluster aware tests are use LAM/MPI for synchronization across nodes. Ensure you have LAM/MPI installed on all nodes of the cluster and on the ocfs2-test build system.

Nodes where ocfs2-test will be executed need to have ssh equivalence set. One should be able to ssh to any node, including the local node, using ssh and not have to enter any password. For safety reason, it is recommended not to use the root to run the tests. Although, there are some tests that will run as root, they are single node and don't need ssh equivalence set for it to run.

Use this script to propagate the ssh public key to other hosts. Do this as the user that runs the test. Also, do it from each node to all other nodes in the cluster.

#!/bin/sh

usage() {
    echo "usage: ${APP} hostname"
    exit 1;
}

SSH=`which ssh`
CAT=`which cat`
APP=`basename $0`

host=$1

if [ -z "${host}" ]
then
    usage ;
fi

${CAT} ~/.ssh/id_dsa.pub | ${SSH} -x ${USER}@${host} cat '>>' ~/.ssh/authorized_keys

exit 0

Some of the tests require the linux kernel source tarball. That tarball can be downloaded from here. (The test script only works with the gzipped source.)

Building and Installing

By default, ocfs2-test will be built to be installed under the /usr/local directory. Since that's not a suitable place to install a test suite and root should not be used to run general tests, it is recommended that the default install directory to be changed to something else. This can be achieved by providing the parameter prefix during the execution of the autogen.sh script.

To build and install ocfs2-test, move to the directory where ocfs2-test was checked out to and do:

$ ./autogen.sh prefix=/
$ make
$ make install DESTDIR=/home/test/ocfs2test  # This will install ocfs2-test binaries under /home/test/ocfs2test

Directory structure

The general directory structure is as follows:

<Install Directory>/bin
                   /log
                   /sbin
                   /workfiles
                   /workfiles/<test name>/<working directories>

Test Source Infrastructure

Before modifying the test source(s), it would be good to try to understand what is out there to support new scripts/programs.

Some of the tests are simple shell scripts, others were written in C and some using python. For those who wish to use Python or Shell Script, under the source directory programs/python_common (yeah.. the name is python_common, but should be just common since it hold shell script config file), one may find a file config.py and config_shell.skel. These two files are configured and installed under the <Install directory>/bin during the make install. The function of these two files is to set variables that reference to the location of the files based on the installation directory. That is why some tests will not work when executed from the source tree.

If the new test is cluster aware, make use of LAM/MPI. For any type of script, one can use run-mpi-parts that is built and installed with ocfs2-test. It is a runtime program that will help synchronize executions in each node.

Running ocfs2-test

In this section, we describe how to run few tests.

Parallel Build Kernel

The parallel build kernel test will fork a build process per directory specified in the list (-d parameter) on each one of the nodes (-n parameter). In addition to the build process, it will also fork a find process on each directory where the node immediately before is building (the first node will fork a find on the last node directories). This find will stress lock migration while the build is running.

Syntax:

$ ./run_buildkernel.py -h
usage: Usage: run_buildkernel.py [-c|--count count] [-n|--nodes nodelist] [-t|--tarfile fullpath tar filename] [-d|--directorylist dirlist] [-l|-logfile logfilename] [-u|--user username] [-h|--help]

options:
  -h, --help            show this help message and exit
  -c COUNT, --count=COUNT
                        Number of times it will build the kernel.
                        Default = 1.
  -u USERID, --user=USERID
                        Userid used to open ssh connections.
  -d DIRLIST, --directorylist=DIRLIST
                        List of directories that will be used by the
                        test.
  -l LOGFILE, --logfile=LOGFILE
                        If logfile is specified, a single logfile will
                        be used by all processes, otherwise,
                        individual logfiles will be created per
                        process. Default will be to create a logfile
                        per process.
  -n NODELIST, --nodes=NODELIST
                        List of nodes where the test will be executed.
  -t TARFILE, --tarfile=TARFILE
                        Fullpath filename of the tar file containing
                        the kernel that will be used.

NOTE: The parameters that accept a list, it will be comma separated without spaces between.

Example:

$ ./run_buildkernel.py  -c 5 -d /ocfs2test1/test,/ocfs2test2/test,/ocfs2test3/test,/ocfs2test4/test,/ocfs2test5/test,/ocfs2test6/test -l /ocfs2test1/test/buildkernel.log -n node1,node2,node3,node4,node5,node6 -t /tmp/workfiles/linux-2.6.20.tar.gz

Cross delete

The cross delete test works in pairs of nodes. At least 2 nodes are need to run this test. But the more the better. If an odd number of nodes is specified, the last will be ignored.

The process is simple. Each node of the pair will extract a copy of the kernel source tree from a tarball (-t parameter). Upon complete, and this will be synchronized, each node will simultaneously start a process to remove the files created by the other node of the pair. Although it is a simple process, it generates a huge amount of DLM traffic.

Syntax:

$ ./cross_delete.py -h
usage: cross_delete.py [-c|count count] [-d|--dirlist dirlist] [-l|-logfile logfilename] [-n|nodes nodelist] [-t|--tarfile fullpathtar filename] [-h|--help]

options:
  -h, --help            show this help message and exit
  -c COUNT, --count=COUNT
                        Number of times the test will be executed.
  -d DIRLIST, --dirlist=DIRLIST
                        Directory where the files will be extracted.
  -l LOGFILE, --logfile=LOGFILE
                        Logfile used by the process.
  -n NODES, --nodes=NODES
                        List of nodes to be used in the test. Must
                        have at least 2 nodes, separated by comma
                        without space.
  -t TARFILE, --tarfile=TARFILE
                        Fullpath filename of the tar file containing
                        the kernel that will be used.

NOTE: The parameters that accept a list, it will be comma separated without spaces between.

At the moment, there is a bug that prevents the program to work with more than one directory in the list, but one is enough to test. I'm considering changing it from a list to a single directory as parameter.

Example:

$ ./cross_delete.py -c 5 -d /ocfs2test1/test -l /ocfs2test1/test/crdel.log -n node1,node2,node3,node4,node5 -t /tmp/workfiles/linux-2.6.20.tar.gz

Last Updated by -- MarcosMatsunaga 2007-02-14 23:32:47