Bull GNU/Linux NFSv4 project

NFSv4 and locks

introduction

Goal

This test is aimed at stressing the fcntl locking functions.
A master process sets a lock on a file region (byte range locking). Several slave processes try to perform operations on this region, such as: read, write, set a new lock ... The expected results of these operations are known. If the operation's result is the same as the expected one, the test succeeds, otherwise it fails.

Locktests stress POSIX locks.

History

This program was written to stress NFSv4 locks.

Download

Download locktests here

Build

make

Run

Local filesystems

-n <num> :

Number of processes to use (mandatory)

-f <file> :

Run the test on a test file defined by the -f option (mandatory)

Example : ./locktests -n 50 -f /file/system/to/test

Network file systems

Since lock tests have been designed to stress NFSv4 locks, they can be used over the network. In the case you use a single client-server connection (one client mounts one directory from the server), lock test usage does not differ from local file system testing. Recent filesystems usually work differently when one or multiple clients access the same file or directory. In this case, it is usefull to stress a network file systems in these conditions.

Multiple clients options

These options have been developed to test network file systems locking when multiple clients try to access the same file.

To work over the network the lock test includes a network test server and a network test clients. Clients and server run the same number of sub-processes. This number is specified to the test server when it starts. Test server runs slave processes plus one master process. Test clients run only slave processes (Plus one synchronisation process which does not perform any test operation). Server master process controls all slave processes, both on server and client machines. Slaves processes on clients and server are referred to slaves without distinction.

Test server :

./locktests -n <number of concurent processes> -f <test file> -c <number of clients>

Test clients :

./locktests --server <server host name>

Server options are:

-n <num> :

Number of processes to use (mandatory)

-f <file> :

Run the test on a test file defined by the -f option (mandatory)

-c <num> :

Number of clients to connect before starting the tests.

Client option is :
--server <server hostname>

Example :
We assume nfs1, nfs2 and nfs3 are three NFS clients mounting the same directory in their own /mnt/nfs/. Specify to the test server 50 concurrent processes. That means each test machine (nfs1, nfs2 and nfs3) will run 50 different process. Specify to the test server 2 test clients (nfs1 and nfs2). Specify to the test server /mnt/nfs/foo as the test file. This path will be used by all test machines (nfs1, nfs2 and nfs3). Test server will wait for two test clients before starting tests.

1. run test server on nfs1 : ./locktests -n 50 -f /mnt/nfs/testfile -c 2
2. run first test client on nfs2 : ./locktests --server nfs1
3. run second test client on nfs3 : ./locktests --server nfs1

How to understand test results

Ten tests are performed:

1. WRITE ON A READ LOCK
2. WRITE ON A WRITE LOCK
3. READ ON A READ LOCK
4. READ ON A WRITE LOCK
5. SET A READ LOCK ON A READ LOCK
6. SET A WRITE LOCK ON A WRITE LOCK
7. SET A WRITE LOCK ON A READ LOCK
8. SET A READ LOCK ON A WRITE LOCK
9. READ LOCK THE WHOLE FILE BYTE BY BYTE
10. WRITE LOCK THE WHOLE FILE BYTE BY BYTE

For each test, the MASTER process takes a lock (READ/WRITE LOCK) and the SLAVE processes try to perform the following operations on the locked section:

• WRITE
• READ
• SET A WRITE LOCK
• SET A WRITE LOCK

If a slave process performs its test operation without error it prints "=", otherwise it prints "x". An operation performed "without error" means:

• The operation (write, read, fcntl ...) returns no error code, and
• errno is not changed.

However, "the slave performs its test operation without error" does NOT mean the "result is correct". For example, a slave process is NOT allowed to set a READ LOCK on an already-set WRITE LOCK. When such operations are performed, the correct and expected result is that the tested function returns the EAGAIN error code.

When all tests have been processed, the result of each process for each test is compared with the table of expected results, and a new table is displayed: For example:

• 200 processes of 200 successfully ran test : READ ON A READ LOCK
• 200 processes of 200 successfully ran test : SET A READ LOCK ON A WRITE LOCK

This result lists the processes/threads both on local and remote machines. Note that the testing locks with thread on multiple clients is disabled because it does not make sense : 2 different clients obviously run at least 2 different processes (thread information cannot be shared over the network).

Expected results

Here is the table of expected results, depending on :

1. Slave test operations (READ, WRITE, SET A WRITE LOCK ... )
2. Master Operation (SET A READ LOCK, SET A WRITE LOCK )
3. Slave types (Processes, threads)
4. Locking profile (POSIX locking, Mandatory locking)

Page maintained by: Vincent ROQUETA		Accessed times since its creation.
	Last update: 2006, April 04