[3125] in SIPB-AFS-requests
[timely] Re: Proceeding with new-rosebud
daemon@ATHENA.MIT.EDU (John Hawkinson)
Wed Aug 19 05:27:31 1998
Date: Wed, 19 Aug 1998 05:27:22 -0400 (EDT)
To: Jonathon Weiss <jweiss@MIT.EDU>
Cc: sipb-afsreq@MIT.EDU
In-Reply-To: "[3122] in SIPB-AFS-requests"
Reply-To: sipb-afsreq@MIT.EDU, beep-jhawk@MIT.EDU
From: John Hawkinson <jhawk@MIT.EDU>
| I'd like to see the cell upgraded to 3.4a before the term starts. Of
| course, I don't have a lot of time to help.
Well, having received some ACKs to my mail from Sunday finally,
I started to try to figure out how to procede over zephyr tonight.
My initial intent had been to schedule a move of of the db servers
on ra and rc to 3.4a on Wed night, and a disabling of the db servers
on rb.
I was reminded about the issue of client timeouts as long as rb
persisted in the CellServDB. I did some experimentation in the zone
cell and confirmed that, while the kernel probably times out once and
caches that state ("lost contact with volume location server..."),
that information doesn't get propagated to utilities like 'vos', etc.,
and it would be inadvisable to leave a significant number of sipb cell
clients with rb in their CSDB for a long period of time (~2 weeks).
Since we would like to wait for the CSDB propagation to take place
before disabling the db servers on rb, we have an interesting problem.
Namely, that rb needs to not become the sync site once the CSDB
is changed, otherwise clients who have taken the new CSDB will not
be able to communicate with it.
There does not appear to be a convenient way of ensuring that
a server does not elect itself as a sync site (feature request?).
We don't seem to have a build tree for AFS 3.3a for Ultrix around.
I upped the quota on /afs/sipb/service/afs and created a symlink
farm in the 'build/' subdirectory, to the 3.3a source tree in the Athena
cell. I applied a patch to ubik/vote.c, and some cosmetic patches
to CML/{state,stamps} to affect the SCCS id.
I won't sent the patch here because of source code issues, but I recommend:
rcsdiff -c10 -r1.1 -r1.2 /afs/sipb.mit.edu/service/afs/build/src/ubik/vote.c
This patch causes uvote_ShouldIRun() to always return
0. uvote_ShouldIRun() is called by ubeacon_Interact() to decide
whether a given host will attempt to become the sync site. Normally it
will only do so if no other "valid" hosts are trying to become the
sync site, or if the last host to try to become the sync site has a
lower IP address.
I'm pretty sure the only likely consequences of this patch are that
either it will work as expected and the patched server will never
become the sync site but the other two servers will, or that the cell
might lose quorum in some situations. I don't think the latter is
likely, based on my limited ubik understanding, but I should mention
it. It can be argued that it is better for the cell to lose quorum
than it would be for some clients to fail to make db changes (because
a loss of quorum would be evident whereas the latter failure might not
be).
I am curious what people think of this patch.
I did a partial build of 3.3a ("make vlserver ptserver SYS_NAME=pmax_ul4"),
which went fine. I followed the instructions in afsdev[587], with
some modifications. It was necessary to add TransArc's "install" to DEST/bin
before starting. Build log is "build.pmax_ul4".
The binaries have some notable information in the SCCS strings for
identification:
[contents-vnder-pressvre!jhawk] /afs/sipb.mit.edu/service/afs/build/pmax_ul4/dest/root.server/usr/afs/bin> what ptserver| more
ptserver:
Base configuration afs3.3 1.68;Nbapi-3.3-1.68.compile.fixes 1.1;Ijhawk-3.3-0000.ubik.never.makes.me.sync.site.SPECIAL 1.1;Ivas
-3.4-3101.sol.xlator.cred.screw.up 1.3;Ivas-3.4-3101.xlator.panic.on.rebooted.xlators 1.2;Ivas-3.4-5675.sol.ftpd.bug 1.4;Ivas-3.4-5685
.ftpd.corrupt.due.to.getpwnam.bug 1.1
Special NON-SYNC-SITE ubik version.
I would like to schedule an outage for Thursday night to update the cell's db
servers to 3.4a (buserver is already there), and to disable the db servers
on rosebud. To do that, I would like to get the Athena cell CSDB change
done as soon as possible. Prior to doing that, I'd like to deploy my
patched ptserver and vlserver.
I would appreciate hearing an ack as to whether people think
this is a terrible idea or not.
It's worth noting that it's difficult to test these binaries. I am inclined
to "just wing it", but would like to get approval from some other
sipb-afs maintainer(s) first.
--jhawk
