CIFS Load Generator source available ...

[Richard Sharpe]

CIFS Load Generator
Developed for SNIA CIFS Benchmarking Working Group
Richard Sharpe
Panasas, Inc & Samba Team
11-Jun-2002

INTRO
This is a short document on how to use the code and where it came from.

BACKGROUND
This code has been extracted from Samba's smbtorture utility.

It is now up on the samba.org site in CVS and can be checked out with:

   cvs co cifs-load-gen

RUNNING IT
To run the code, simply execute ./bin/cifs_bm after having configured and 
made the code.

  ./bin/cifs_bm -U<user%pass> -Wworkgroup -c <client-file> [-N clients] \
      [-I<ip>] [-b >num>] //server-or-ip/share


NOTE. You need to know the max size of WriteX or ReadXs in the client file, 
as cifs_bm defaults to 256*1024. Use a flag of '-b <num>' for the block size
you want. For example, '-b 1024' will give you a buffer of 1024*1024 bytes.

THE CLIENT FILE
The client file is essentially the same as smbtorture uses. There are a number of them in the clients directory.  

Each consists of a series of lines, each with either an operation to perform 
on the server, or one of a number of special keywords.

The keywords are:

BM_SETUP: Provides a series of setup operations. Currently, the driver does
noting with this command, except set an internal variable called state to
BM_SETUP. No measurements are taken during this phase.

BM_WARMUP: Provides a series of warmup operations. Currently, the driver does nothing with this command, except set an internal variable called state to BM_WARMUP. No measurements are taken during this phase.

BM_MEASURE: Provides a series of operations that will be measured.

RECONNECT: Disconnect from the server and reconnect to it.

SYNC <n>: Wait for up to <n> seconds for the master to say go. It waits for all the clients to SYNC.

There are about 14 commands that are implemented. Look at the collection of 
.txt files to get an idea of what they are ...

Some of the bit fields are important. For example, on an:

  NTCreateX <file> <flag1> <flag2> <FID> 

command, <flag2> needs the 0x01 bit set if it is to ignore failures due to 
files already existing.

An additional command is: Lock <file> etc ... Check the code for params for
now.

PROBLEMS
There are still many problems. 

1. It would be nice if the child/client processes would synchronise each 
   phase with each other. A Sync command is now implemented.

2. FIND NEXT is not really implemented. This needs doing.

3. More operation types are needed. Lock is now implemented. However, see
   below.

4. Some way to generate a load file would be nice.

5. There is no way to specifiy a schedule of users and passwords to use to
   log onto the server.

6. NetBench specifies its driver file as a series of parts, each part 
   containing a series of commands. It then randomizes the order of the 
   parts. It would require a rewrite of cifs_bm to achieve this.

7. There is no way yet to spread the load over a series of interfaces.

8. There is no way to separate out connection to server, logging in and 
   connection to the share. They are all one event. Thus we cannot measure
   the server's ability to handle logons (SessSetup&X), connections
   (probing its ability to fork or create threads), and connecting to shares
   (TCON etc). This calls for commands like: Tcon <share>, Tdis <share>, 
   etc.

9. The latency info needs to be kept in long longs, and the read and write
   throughput needs to be cleaned up.

10. It would be nice to have an embedded programming language, like TCL or
    ...

11. It has been suggested by a guy from Sun that the current model of one
    process per client might be affected by scheduler latencies. In addition
    if we want to simulate really large numbers of clients, we might need to
    move to a multi-threaded client.
 
Regards
-----
Richard Sharpe, rsharpe at ns.aus.com, rsharpe at samba.org, 
sharpe at ethereal.com