[3129] in SIPB-AFS-requests
Re: [timely] Re: Proceeding with new-rosebud
daemon@ATHENA.MIT.EDU (John Hawkinson)
Fri Aug 21 13:39:57 1998
Date: Fri, 21 Aug 1998 13:39:48 -0400
To: Jonathon Weiss <jweiss@MIT.EDU>
Cc: sipb-afsreq@MIT.EDU
In-Reply-To: "[3128] in SIPB-AFS-requests"
From: John Hawkinson <jhawk@MIT.EDU>
At this point, since there has not been much said either way, my
intent is to delay the move to 3.4a until such time as the Solaris
rosebud is ready. Hopefully that will be the tail end of next week.
I'll be doing some more work on it tonight and I'll try to document
where we stand on it then.
My intent is to go ahead with the listed plan, however jhutz suggested
that it would be appropriate to changeaddr old-rosebud and bring up
new-rosebud before doing the volume moves, as opposed to doing the
volume moves and then changeaddr's new-rosebud to old-rosebud. That
seems reasonable since it means we can run db servers on new-rosebud
sooner, minimizing the db server outage.
| I have not looked at your patch, but I am concerned that if rc goes
| down, the cell will end up without quorum. It is my guess that if rc
| goes down, ra will vote for rb, and rb with either fail to vote or
| vote for rc, either way no server will have a majority of the votes.
| Could you explain why you think this won't happen.
My understanding of ubik is that a server will never vote for another
server who is not voting for themselves. I.e. ra would never vote for
rb unless rb voted for rb.
At this point, this is largely moot, but if I have some free time
I may build a version of this patch for 3.4a, ideally with a cmdline
flag, and test it in the zone cell, and perhaps request it be sent to
transarc.
--jhawk
