[OpenAFS] interesting day at the the afs bazzar

[ted creedon]

FYI:

mount -t smbfs //bigserver/bigarchive /mnt -ousername=3Dmylogin
cd /afs/.mycell/bigafsarchive  #bigafsarchive.vol
cp -rp /mnt/* .

...some files copied but then "can't stat /afs/.mycell/denali/..." error
appeared from the cp command. Then:

1. Linux 1.2.11 afs server and client hung
2. /afs was turned into /afs* (that's right looked like an executable)
3. Win 2K clients hung

/mnt was about 80 Gig or mixed linux/win filenames on a ntfs partition =
on
bigserver. no single file larger than 680Meg

looks like the quota's on /afs/.mycell/bigafsarchive were set at 5000 =
was
the problem. Set all to 0

went to Bill gates filesystem and removed uninteresting files. Ran it =
again
and it completed with minor gripes

The afs crashes are interesting

I'll continue abusing your filesystem

afs is neat.

Tedc

i.e. a cp crash took out afs


-----Original Message-----
From: openafs-info-admin@openafs.org =
[mailto:openafs-info-admin@openafs.org]
On Behalf Of S.J.Chun
Sent: Wednesday, January 28, 2004 8:13 AM
To: openafs-info@openafs.org; Derrick J Brashear
Subject: [OpenAFS] Re: [OpenAFS] Help: intermittent fileservice hangs

We also have the same kind of problem, And when I did rxdebug =
(fileserver)
7000,
it says

Trying XX.XX.XX.XX (port 7000):
getstats call failed with code -1

Any clue, here ?

Thanks in advance.

  ----- Original Message -----
  From: Derrick J Brashear <shadow@dementia.org>
  To: openafs-info@openafs.org
  Sent: Tue, 27 Jan 2004 13:05:47 -0500 (EST)
  Subject: Re: [OpenAFS] Help: intermittent fileservice hangs

  On Tue, 27 Jan 2004 cball@bu.edu wrote:
 =20
  > Over the past weekend we had numerous, intermittent AFS access =
problems.
 =20
  Guess: you were running out of threads.
 =20
  rxdebug (fileserver) 7000
  when it's happening.
 =20
 =20
  > read-write below the WWW root directory.  Switching the WWW root =
into
  > "maintenance mode" (an alternate root directory volume with =
read-only
  > mounts) solved the problem.  Monday the original scenario was =
restored;
  > we've gone 30 hours without a relapse.
 =20
  Too many callbacks being broken, perhaps.
 =20
  > Fileserver and database server logs showed nothing out of the =
ordinary.
  > This is a fundamental concern; while different options may be
appropriate
  > it is quite disturbing to transition into a non-functional state =
with
  > nothing in /usr/afs/logs [that I understand] to indicate a problem.
 =20
  kill -TSTP fileserver-pid
 =20
  turns up the logging, which goes in /usr/afs/logs/FileLog
 =20
 =20
  > "-p <#processes>" options which appear to be interesting.  Is there =
a
way
  > to query or log utilization levels or to get an indication when =
limits
are
  > exceeded?
 =20
  Look at the threads as above. the xstat_fs_test program also exposes =
some
  useful data
 =20
  > What can or should be monitored to expose (and log) activity levels,
  > timeouts, etc.
  _______________________________________________
  OpenAFS-info mailing list
  OpenAFS-info@openafs.org
  https://lists.openafs.org/mailman/listinfo/openafs-info
 =20

_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info