CIFS Load Generator source available ...
Ulf Bertilsson
ulf.bertilsson at adcomdata.no
Thu Jun 27 05:46:04 GMT 2002
Anybody with an tarball laying around ? :)
> -----Original Message-----
> From: Richard Sharpe [mailto:rsharpe at ns.aus.com]
> Sent: Thursday, June 27, 2002 8:08 AM
> To: samba-technical at lists.samba.org
> Subject: CIFS Load Generator source available ...
>
>
> 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
>
>
>
More information about the samba-technical
mailing list