[663] in testers
AFS system packs
daemon@ATHENA.MIT.EDU (daemon@ATHENA.MIT.EDU)
Fri May 11 07:23:44 1990
Date: Fri, 11 May 90 07:23:24 -0400
To: testers@MIT.EDU
Cc: bug-afs@MIT.EDU
From: Richard Basch <probe@MIT.EDU>
<sigh>... there are still problems with using AFS for system packs
still. I have personally encountered the following problems:
- During the update, if the only rep. site is a read-only clone, just
after the original clone is destroyed and the new one is created,
there is a window of vulnerability in which the client may discover
things don't exist (and it reports not found). In fact, after this,
if the client tries accessing the volume as it is being re-cloned
you get no such device (I think this will only occur if the first
has occurred, otherwise, I believe you will get a device busy).
The side effect of all of this is that if you hit this 1-second
window, unexpected things may result. One time, I was simply requesting
a program to be loaded from the packs, and it simply gave me "not
found". Another time, I was actively using xterm, and it died. In
fact, shortly, all my xterms died and my session died (thank god, the
vos release went to completion on its own).
However, it seems that if you miss this small window of vulnerability,
you are safe. The new client seems to detect data version mismatches
and reloads data from the readonly volume, if necessary. The old client
would persist in giving errors after vos releases in certain cases when
the data versions did not match. This will at least no longer require
the use of "fs checkb".
The new problem described above also does not require any manual
intervention to recover from. As soon as the release is complete,
normal operation is resumed. I am unclear as to whether this will
happen if there is a replication site on a different partition. This
supposedly will do an incremental restore, so I would expect that the
clients would detect a missing volume, go to the other site, and
discover it is locked and print out a warning about there being a busy
volume.
-Richard