CIFS Load Generator source available ...

Esh, Andrew AEsh at
Thu Jun 27 09:03:05 GMT 2002

I ran into a compile problem on Linux Redhat 7.1. Here is a patch that fixes

Index: include/
RCS file: /cvsroot/cifs-load-gen/source/include/,v
retrieving revision 1.1
diff -u -r1.1
--- include/	27 Jun 2002 04:40:18 -0000	1.1
+++ include/	27 Jun 2002 16:01:52 -0000
@@ -19,13 +19,13 @@
 /* Define if you have the <sys/ipc.h> header file.  */
-#undef HAVE_SYS_IPC_H 1
+#undef HAVE_SYS_IPC_H
 /* Define if you have the <sys/shm.h> header file.  */
-#undef HAVE_SYS_SHM_H 1
+#undef HAVE_SYS_SHM_H
 /* Define if you have the <sys/socket.h> header file.  */
 /* Define to `int' if <sys/types.h> doesn't define.  */
 #undef mode_t

and a cleanup:

RCS file: /cvsroot/cifs-load-gen/source/,v
retrieving revision 1.1
diff -u -r1.1
---	27 Jun 2002 00:41:53 -0000	1.1
+++	27 Jun 2002 16:00:54 -0000
@@ -20,7 +20,6 @@
 INSTALLCMD=/usr/bin/install -c
 # XXX: Perhaps this should be /bin/sh instead -- apparently autoconf

-----Original Message-----
From: Richard Sharpe [mailto:rsharpe at]
Sent: Thursday, June 27, 2002 1:08 AM
To: samba-technical at
Subject: CIFS Load Generator source available ...

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

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

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

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

   cvs co cifs-load-gen

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 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

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

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>, 

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.
Richard Sharpe, rsharpe at, rsharpe at, 
sharpe at

-------------- next part --------------
HTML attachment scrubbed and removed

More information about the samba-technical mailing list