[OpenAFS] Crash testing OpenAFS

[chas williams - CONTRACTOR]

ted, please answer my questions.

what is the network configuration?

what do you mean by crash?  this has never been clear to me.  does
the openafs client box (the one running the cp -rpv) lockup?  does
it simply stop copying?  if it locks up are there messages on the
console that say something about an "oops"?

what happens when you copy the generated directory tree from one
local volume to another local volume (both source and destination
volumes are located on you local afs fileserver running 1.3.87 on
your local 
network).

In message <20050815161440.3390EC2C7@smtpauth.easystreet.com>,"ted creedon" wri
tes:
>You are correct, originally I created 1 meg files and reduced them in size.
>
>Not only does this directory crash Linux but 2 others do too.
>
>Linux does not crash then copying from the 1.2.11 fileserver to
>/root/filename on the 1.3.87 client.
>
>Suggest using a loopback filesystem or manual mount for /usr/vice/cache to
>prevent problems on reboot.
>
>tedc
>
>-----Original Message-----
>From: openafs-info-admin@openafs.org [mailto:openafs-info-admin@openafs.org]
>On Behalf Of chas williams - CONTRACTOR
>Sent: Monday, August 15, 2005 8:55 AM
>To: ted creedon
>Cc: openafs-info@openafs.org
>Subject: Re: [OpenAFS] Crash testing OpenAFS 
>
>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.
>_______________________________________________
>OpenAFS-info mailing list
>OpenAFS-info@openafs.org
>https://lists.openafs.org/mailman/listinfo/openafs-info
>
>
>_______________________________________________
>OpenAFS-info mailing list
>OpenAFS-info@openafs.org
>https://lists.openafs.org/mailman/listinfo/openafs-info
>