[13928] in Athena Bugs
Re: vos
daemon@ATHENA.MIT.EDU (Richard Basch)
Tue Oct 17 10:16:52 1995
Date: Tue, 17 Oct 1995 10:15:53 -0400
To: jweiss@MIT.EDU
Cc: miki@MIT.EDU, bugs@MIT.EDU, afsdev@MIT.EDU, marc@MIT.EDU
In-Reply-To: <199510162134.RAA26146@the-other-woman.MIT.EDU>
From: "Richard Basch" <basch@lehman.com>
On Mon, October 16 191995, "jweiss@mit.edu" wrote to "miki@MIT.EDU, bugs@MIT.EDU, basch@lehman.com, afsdev@MIT.EDU, marc@MIT.EDU" saying:
>
> is there ever going to be a vos for sgi? I know transarc has one. it
> is horrendously broken or something?
>
> I've been meaning to send mail to afsdev about this for a little while
> now. It is my understanding that, in the past, before vos, bos, etc.
> binaries were put into the afsuser locker they were "blessed" by
> Richard. I'm not sure what this "blessing" consisted of. Miki, would
> it be possible for you to "bless" a set of binaries for the SGI?
> Richard (or anyone else) can you outline the "blessing" process?
>
> Jonathon
As long as there were no major bugs that I fixed in 3.3a, that version
should be ok. Of course, it will lack some of the operational features
I added for the convenience of specifying partitions for where to obtain
a dump (I found it occassionally useful to dump the contents of an RO
volume on a particular partition in order to find out what was going on,
and as I understand it, this feature is sometimes used by Operations).
Essentially, I always viewed "vos" as being for operational use, and
therefore, I would never risk having a version of "vos" that I suspected
to have problems to accidentally be invoked by an administrator who
happened to forget about the particular problems (or who wasn't informed).
While users found it useful, they couldn't inadvertently create
inconsistencies in the cell, like an administrator (and it has happened,
to those who should have known...)
In terms of what I look for:
1. I almost always do a quick code-diff between the two versions... I
have occassionally found some serious problems as a result in a new
version, as distributed by Transarc. All of vos' critical logic is
actually in the client, not the servers, and they sometimes don't do
things in an operationally-safe order if it gets interrupted (such as by
a power hit).
2. I try out vos move and vos release and watch the transactions, since those
two operations are the most complicated and most dangerous.
3. I try to make sure I follow all discussions on Transarc lists and
pick up any patches for any of their advisories (and 2 out of 3 have
a patch for vos).
#1 is the most important... I have found at least 3 different versions
to be faulty in the past... By the way, I would certainly do it for 3.4
when that comes out, as they have now introduced parallel releases, and
I have not verified the code logic. It is a nice feature, if they
implemented it correctly.
--
Richard Basch
Lehman Brothers, Inc. Email: basch@lehman.com
101 Hudson Street 33rd Flr. Fax: +1-201-524-5828
Jersey City, NJ 07302 Voice: +1-201-524-5049
