yep, size to fail follows the cache size. 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.
It may not be the same problem, but right now I'm shooting at anything that moves. 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: [EMAIL PROTECTED] University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 > -----Original Message----- > From: chas williams [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, July 30, 2002 11:13 AM > To: Neulinger, Nathan > Cc: [EMAIL PROTECTED] > Subject: Re: [OpenAFS-devel] reproducible problem during cache flush > > > In message > <[EMAIL PROTECTED]>,"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. > > this seems similar to complaints from [EMAIL PROTECTED] on > the -info list (he was using 1.2.5 though). is this a linux client? > smp? i am going to guess that if you use a bigger cache this problem > disappears right? > _______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
