[304] in Release_7.7_team
Re: SGI Points
daemon@ATHENA.MIT.EDU (Richard Basch)
Wed May 10 08:36:51 1995
Date: Wed, 10 May 1995 08:36:16 -0400
To: Mike Barker <mbarker@MIT.EDU>
Cc: acmg@MIT.EDU, dcns-dev@MIT.EDU, release-team@MIT.EDU, skunks@MIT.EDU,
ops@MIT.EDU, tjm@MIT.EDU, gjackson@MIT.EDU, nschmidt@MIT.EDU,
carla@MIT.EDU, bmurphy@MIT.EDU, bwmelans@MIT.EDU, kim@MIT.EDU,
vrt@MIT.EDU, cfields@MIT.EDU, dot@MIT.EDU, alexp@MIT.EDU
In-Reply-To: Mike Barker's message of Tue, 09 May 1995 17:20:01 EDT,
<9505092120.AA07507@gulch.MIT.EDU>
From: "Richard Basch" <basch@MIT.EDU>
. . .
5. The XZ SGI running IRIX 5.3 will have AFS 3.4 client software installed
6. The AFS 3.4 client software will operate correctly with AFS 3.3a
server software.
Yes, the client software will be interoperable with AFS 3.3a server software.
If there had been any planned incompatibilities, there would have been
an outcry, but there would have at least been some forewarning. Currently,
the only enhancements I know are support for even more replication sites,
which we might not be able to take advantage of (then again, we don't use
as much as the original limit in AFS 3.0-3.2).
It seems to me that there are several questionable assumptions in this
set of conditions. Perhaps the most critical ones involve the
availability of AFS 3.4, since Transarc has yet to release a version
of this software.
There is one more issue regarding AFS 3.4. Besides the fact that beta is
now about two months late, their proposed piece-meal release indicates a
general lack of stability in AFS 3.4. The reason I never pushed for Athena
to update to AFS 3.3 servers was because of its stability (3.3a proved stable).
It is even more frightening to see that they see different instabilities
for the same architecture but slightly different processor configurations,
because this may be a general problem with locking and cache maintenance.
From experience, they rarely release a stable product initially, and it
is seldom of this poor quality for beta. Usually, even the alpha code is
better than what they are describing. My advice is to proceed with caution,
and at this point, I do not think AFS 3.4 is viable for clients until
the IAP release. (Do with this what you will... I am merely giving my
opinion as to how I would proceed if I were still there.) Perhaps, if
AFS 3.3a is as bad as I hear it might be with regards to IRIX 5.2, you
are simply choosing between two evils (and only in this case, would I
even consider deploying AFS 3.4 on a client) -- I played that game with
Solaris when there were no good choices. If there is only one problem
with AFS 3.3a under IRIX, try looking at the 3.4 source code for the patch.
Cache corruption is a far worse problem than incorrectly handling one
compile case, which is most likely a simple mistake in the virtual memory
or vnode management for that platform.
I believe we need to collect information about the following:
a. What AFS versions work under IRIX 5.3? What fixes the current problem?
(Transarc?)
The first version of AFS that supports IRIX 5.3 is AFS 3.4. This is already
a known fact. Retrofitting IRIX 5.3 support into AFS 3.3a is probably a
major effort (I can determine this in a few hours, if necessary). Also, be
aware, such a retrofit will prohibit effective use of Transarc's support
lines, if you consider that of any value.
b. Can XZ equipped SGI's run IRIX 5.2/AFS 3.3a? Why not? What problems?
(SGI?)
Sorry, don't have any comments on this one, because I do not know what
"XZ equipped" means. The answer is it will probably work as well as the
current AFS, as long as it is the same processor, OS version, and no
special processor hardware (eg. dual processor).
-Richard
