[OpenAFS-devel] Re: afsfsperf ported to OpenAFS (for modern rx)

Ragnar Sundblad ragge@csc.kth.se
Sat, 20 Feb 2010 02:26:10 +0100


On 20 feb 2010, at 01.05, Jeffrey Altman wrote:

> Ragge:
> 
> While I would certainly like to see something like afsfsperf
> built as part of OpenAFS I question whether what OpenAFS wants
> is a port from Arla or a test implementation that sits a top
> the OpenAFS UKERNEL build for Unix (or a special mode in
> afsd_service.exe for Windows that can be executed from the
> command line.)
> 
> What are your thoughts?

My thoughts are that I hadn't even thought of UKERNEL. :-)

Wouldn't an UKERNEL afsfsperf rather test the client system,
or maybe better described, the client+server combination?
If so, that could certainly be a useful tool in itself, and I
think both programs could fill different needs.

I'd like to add that afsfsperf stands directly upon rx and almost
nothing else, and I had to change very little to make that build
with OpenAFS rx instead. Just a few struct fields that had more
modern names and similar. The rest of the stuff in the libraries
is mostly general convenience things that has little to with afs.

So there is no glue code or anything to rip out Arla and insert
OpenAFS instead, and I think the code could almost be taken for a
native OpenAFS program. afsfsperf is pretty small, just one C file,
1063 lines. With all the convenience stuff used it is about 8000
lines (and one could probably trim that down a bit more if one
wanted to).

/ragge


> 
> Jeffrey Altman
> 
> 
> On 2/19/2010 6:17 PM, Ragnar Sundblad wrote:
>> 
>> Yes, I should mention that this is a file server benchmarking tool.
>> 
>> It measure the speed of file servers without going through the
>> local cache, it is an ordinary userland program that talks directly
>> to the server. It is normally tricky to benchmark a file server by
>> just using the client, since that tends to be more a test of the
>> client than the server. (At least in my experience.)
>> 
>> afsfsperf creates and deletes files and directories, reads and writes
>> data and such. It is pretty easy to change to create your own tests.
>> 
>> I how found it pretty useful when setting up new servers to test the
>> actual result.
>> 
>> /ragge
>> 
>> On 18 feb 2010, at 11.45, Ragnar Sundblad wrote:
>> 
>>> 
>>> I have made a first step to break out afsfsperf from Arla
>>> and run it with more recent rx from OpenAFS. Maybe it should
>>> be called a feasibility test, or proof of concept, or something.
>>> 
>>> I don't know of any other similar tool.
>>> 
>>> Is this interesting to anyone else?
>>> 
>>> If so, I'd be more than happy if someone else could help a little,
>>> or maybe even pick up from here, as I don't really have the time to
>>> work on this at the moment, and I don't need anything more out
>>> of it right now than what it already does.
>>> Besides, I am not really familiar with neither the Arla nor the
>>> OpenAFS code or coding style, so I am probably pretty far from a
>>> good pick for this job.
>>> 
>>> I think it would be nice to have afsfsperf as part of the OpenAFS
>>> distribution.
>>> 
>>> Or maybe this is a bad approach, perhaps one should abuse these
>>> codebases in another way?
>>> 
>>> You can find it here:
>>> <http://www.csc.kth.se/~ragge/afsfsperf-openafs.tgz>
>>> 
>>> All code was picked from arla-0.90:
>>> <ftp://ftp.stacken.kth.se/pub/arla/arla-0.90.tar.gz>
>>> 
>>> /ragge
>>> 
>>> -------------------------
>>> README.txt 
>>> -------------------------
>>> 
>>> 2010-02-18, Ragnar Sundblad <ragge@csc.kth.se>
>>> 
>>> This is a crude, first step in porting the Arla program "afsfsperf" to
>>> OpenAFS. I had to break out some stuff from some Arla libraries that
>>> it depends upon.
>>> 
>>> It kind of works, but there are a few problems left:
>>> - the bulkstat test crashes for some reason, hopefully be easy to
>>> fix. I have commented the test out for now.
>>> - assertion fail in rxkad_thr_stats_init if you have tokens when you
>>> run it - do unlog first! Only unauthenticated and unencrypted
>>> testing is currently possible. I don't expect this to be hard to fix
>>> for someone that actually understands what is supposed to happen
>>> here (<= not me, at least not just yet).
>>> 
>>> Other things left to do:
>>> - In a better world, Arla's libroken should be broken out in its whole
>>> as a stand alone library.
>>> - Clean up ugly shortcuts I've taken.
>>> - Make it portable.
>>> 
>>> It was ported and built on recent opensolaris. To make it compile on
>>> other platforms you will probably have to changes things a little.
>>> 
>>> -------------------------
>>> 
>> 
>> _______________________________________________
>> OpenAFS-devel mailing list
>> OpenAFS-devel@openafs.org
>> https://lists.openafs.org/mailman/listinfo/openafs-devel
>> 
>