CIFS Load Generator source available ...
rsharpe at ns.aus.com
Wed Jun 26 21:57:02 GMT 2002
CIFS Load Generator
Developed for SNIA CIFS Benchmarking Working Group
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 samba.org 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
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 ns.aus.com, rsharpe at samba.org,
sharpe at ethereal.com
More information about the samba-technical