Ok. I narrowed it down. Attempting to make a symlink with target length > 1024 will immediately cause client to lose contact with file server on linux.
This appears to be linux specific, and is not specific to recent client builds, even happening on an old 2.2.x build I have. -- Nathan ------------------------------------------------------------ Nathan Neulinger EMail: [EMAIL PROTECTED] University of Missouri - Rolla Phone: (573) 341-4841 Computing Services Fax: (573) 341-4216 > -----Original Message----- > From: Neulinger, Nathan > Sent: Friday, March 22, 2002 9:27 AM > To: [EMAIL PROTECTED] > Subject: RE: [OpenAFS-devel] reproducible afsd/libafs lockup > > > Appears this test causes it: > > troot-srvtst07(132)> fs checks ; ./fsstress -v -n 8 -p 1 -d > /umr/u/nneul/fsstress/ > All servers are running. > seed = 1016547366 > 0/0: dwrite - no filename > 0/1: chown . 7536 0 > 0/2: creat f0 x:0 0 0 > 0/3: symlink l1 0 > 0/4: fdatasync - no filename > 0/5: symlink l2 110 > 0/6: truncate - no filename > 0/7: creat f3 x:0 110 0 > > I'm trying to track down a more specific trigger. > > -- Nathan > > ------------------------------------------------------------ > Nathan Neulinger EMail: [EMAIL PROTECTED] > University of Missouri - Rolla Phone: (573) 341-4841 > Computing Services Fax: (573) 341-4216 > > > > -----Original Message----- > > From: Neulinger, Nathan > > Sent: Friday, March 22, 2002 9:15 AM > > To: [EMAIL PROTECTED] > > Subject: RE: [OpenAFS-devel] reproducible afsd/libafs lockup > > > > > > Interesting... I grabbed fsstress from kolya's web page and started > > running it on this station. The instant I start running it > against an > > afs directory that client loses contact with the server > that the test > > afs dir is located on. Running fs checks regains connection. > > And that is > > with a -p 1 test. Haven't even tried the -p # for larger #. > > > > -- Nathan > > > > ------------------------------------------------------------ > > Nathan Neulinger EMail: [EMAIL PROTECTED] > > University of Missouri - Rolla Phone: (573) 341-4841 > > Computing Services Fax: (573) 341-4216 > > > > > > > -----Original Message----- > > > From: Neulinger, Nathan > > > Sent: Friday, March 22, 2002 8:51 AM > > > To: [EMAIL PROTECTED] > > > Subject: [OpenAFS-devel] reproducible afsd/libafs lockup > > > > > > > > > Have not dug into this much yet, but with recent (and > maybe old, not > > > sure since I don't have a machine I can hose at the moment that is > > > running old code) builds, I can trigger a real quick complete > > > cm lockup > > > by doing this in a high level directory in my cell. (i.e. > a dir with > > > alot of stuff under it). > > > > > > find . -follow -type f -print | xargs -P 8 -n 30 wc > > > > > > This one is a different symptom and situation from the > other problem > > > I've been talking about. In that problem, you can still > talk to the > > > cache manager with cmdebug and fs. With this one, the cm > is totally > > > non-responsive. > > > > > > -- Nathan > > > > > > ------------------------------------------------------------ > > > Nathan Neulinger EMail: [EMAIL PROTECTED] > > > University of Missouri - Rolla Phone: (573) 341-4841 > > > Computing Services Fax: (573) 341-4216 > > > _______________________________________________ > > > OpenAFS-devel mailing list > > > [EMAIL PROTECTED] > > > https://lists.openafs.org/mailman/listinfo/openafs-devel > > > > > _______________________________________________ > > OpenAFS-devel mailing list > > [EMAIL PROTECTED] > > https://lists.openafs.org/mailman/listinfo/openafs-devel > > > _______________________________________________ > OpenAFS-devel mailing list > [EMAIL PROTECTED] > https://lists.openafs.org/mailman/listinfo/openafs-devel > _______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
