[OpenAFS-devel] reproducible problem during cache flush

[Neulinger, Nathan]

yep, size to fail follows the cache size.=20

I've got this machine rebuilt with kdb enabled, and can
destroy/hang/whatever at will, so if you want into it, or want me to do
something, let me know.=20

It may not be the same problem, but right now I'm shooting at anything
that moves.=20

linux client, 2.4.19-SMP, UP box, latest protos build (should be mostly
similar to cvs trunk where it matters)

-- Nathan

------------------------------------------------------------
Nathan Neulinger                       EMail:  nneul@umr.edu
University of Missouri - Rolla         Phone: (573) 341-4841
Computing Services                       Fax: (573) 341-4216


> -----Original Message-----
> From: chas williams [mailto:chas@cmf.nrl.navy.mil]=20
> Sent: Tuesday, July 30, 2002 11:13 AM
> To: Neulinger, Nathan
> Cc: openafs-devel@openafs.org
> Subject: Re: [OpenAFS-devel] reproducible problem during cache flush=20
>=20
>=20
> In message=20
> <4E39457CA36BA347A9940A14D48B11A90B06D6@umr-mail2.umr.edu>,"Neulinge
> r, Nathan" writes:
> >Running iozone -a on a recent protos branch build (probably trunk as
> >well), with a 25 MB cache, I usually see a afs lockup at 32768/8192,
> >with a 10MB cache, at 16384/16384.=20
>=20
> this seems similar to complaints from vvs@germanistik.fu-berlin.de on
> the -info list (he was using 1.2.5 though).  is this a linux client? =20
> smp?  i am going to guess that if you use a bigger cache this problem
> disappears right?
>=20