We encountered the same problem a while back and contacted Transarc about the
new "feature." They took a look at it and devloped a command line option
(-dontdelay) that can be specified to the fileserver process that will fix the
problem you are seeing. Of course it leaves you open to denial of service
attacks which was Transarc's motivation for putting the delays in in the first
place. We've tested the patch here and it seemed to work well. We are waiting
for them to incorporate it into an official patch release before we deploy it
operationally. They could not give me a definite release date for an official
patch but they seemed to think one would be out soon. Refer to Transarc Report
TR-60489.
Mike
> Date: Mon, 18 Dec 2000 18:26:27 -0600
> From: Nathan Neulinger <[EMAIL PROTECTED]>
> X-Accept-Language: en
> MIME-Version: 1.0
> To: [EMAIL PROTECTED], [EMAIL PROTECTED]
> Subject: Transarc AFS 3.6 2.5 server release AAARRRGGGHHH!!!!
> Content-Transfer-Encoding: 7bit
>
> Today we did a major AFS server upgrade that has been delayed for far
> too long. Unfortunately thanks to an (apparently, I might have missed
> it, but it sucks regardless) undocumented new feature in the 2.5 patch
> release - we wound up having problems for about 8 hours with NT clients
> unable to talk to the server.
>
> Apparently the 2.5 code has a nwe delta in it that causes servers to
> stop talking to clients completely when it thinks that they are flooding
> the server with requests. There is no way to tell that this is
> happening, no way to shut it off, and no way to get a list of affected
> stations.
>
> In our case, almost 1500 NT stations with the AFS client had extremely
> sporadic and unstable access to afs. What would happen is - the fs
> checks output woult include all of the servers running 2.5, or some
> selection of them.
>
> So - if you're thinking of upgrading to 3.6 2.5, think twice, or at
> least be very cautious about it. Shutting down all your clients ahead of
> time, and SLOWLY bringing them back up might help, but that's hardly an
> option with 1500 stations.
>
> The end result - we wound up backing down to 3.6 2.3 (a huge upgrade
> from the 3.4a 5.53 we were running), which fixed the problem.
>
> (To openafs gatekeepers - if you get a delta from transarc/ibm [yeah
> right!] that includes this, I _STRONGLY_ suggest that you say 'no
> thanks!' or at the very least, make the feature optional.)
>
> BTW - this doesn't seem to affect unix clients. It only affected the NT
> clients, runnig 3.5 or 3.6, didn't seem to matter which, although the
> particular behavior differed with 3.5 and 3.6.
>
> -- Nathan
>
> ------------------------------------------------------------
> Nathan Neulinger EMail: [EMAIL PROTECTED]
> University of Missouri - Rolla Phone: (573) 341-4841
> CIS - Systems Programming Fax: (573) 341-4216
-------------------------------------
Mike Mosley
Systems Software Developer
College of Engineering, UNC-Charlotte
