[OpenAFS] Crash testing OpenAFS

chas williams - CONTRACTOR chas@cmf.nrl.navy.mil
Mon, 15 Aug 2005 11:55:13 -0400


In message <20050815150504.4AAF3BF44@smtpauth.easystreet.com>,"ted creedon" wri
tes:
>ftp://creedon.dhs.org/afs_stress_test/run0/
>ftp://creedon.dhs.org/afs_stress_test/run1 

i recreated your test directory tree locally.  i am puzzled about
a few things though.  for instance:

	#!/bin/bash
	#set -x #if one is curious..
	dd if=/dev/zero of=1meg bs=256K count=1
	cp 1meg "./TESTDIR.TMP"
	cp 1meg "./ADAPTEC/ACMWrapperServer.A021.dll"
	cp 1meg "./ADAPTEC/ACMWrapperServer.A884.dll"
	cp 1meg "./ADAPTEC/CdCopier.A021.exe"

i would hazard that this is creating 256k files, not 1M files.
the total volume size, after running ./mkdirs, ./mkfiles, ./mk1megfiles
was about 5.6G.  is this corect?

i was able to copy this tree from one volume to another on a different
server (within our local afs cell).  the servers are amd64_solaris10
running openafs 1.3.81.  the afs client machine which did the create
and subsequent copy, was i386_2.6.13-rc3 running openafs 1.3.87.

your tcpdump leads me to believe that atleast part of these tests is
behind a NAT.  is this true?  further, the tcpdump from run1 looks 
incomplete.  the end of the dump still seems to show data transfer.

the fstrace output from run0 is useless.  you need to install the
afszcm.cat in order to get something human readable.

cmdebug from run0 looks unremarkable.  the client doesnt not appear
to be wedged in anyway.

conclusions:  i would guess that the 1.3.87 openafs client is stable.
perhaps you could trying building and running an older set of afs server
binaries, say 1.3.81.