First of all, we too have had problems with X freezing on the RS6K. I
don't know what the cause was, but I doubt that it was due to updating
X binaries, since it seemed to hang at least once a week, but the
X server isn't updated more than once or twice a year.
Paul Blackburn <[EMAIL PROTECTED]> writes:
> What happens when you vos release the X11 stuff?
> Of course, the binaries on the server(s) get updated.
...
> the server will get a chunk of the new binary. I think that mixing
> pages of the old and new binaries won't work and will have unpredictable
> results (eg X11 freezes or program core dumps).
Precisely. This is the same sort of problem one has when updating
binaries on an NFS server. AFS is only partly stateful, hence these
sorts of problems. The solution is to avoid overwriting executables,
especially long-running ones like the X server, or window manager,
xterm, or emacs. Instead, move them into a .deleted directory, and
create a new file. After doing the vos release, you can rm everything
in .deleted. This works perfectly as long as nobody uses these
executables for longer than the inter-release interval. Obviously you
can extend this scheme by using .deleted1 and .deleted2, etcetera.
DFS addresses this problem by introducing OPEN tokens, so the server
can know whether a client is using a file, and keep it around after it
has been unlinked, so you won't need to screw around with .deleted
directories anymore.
Lyle Transarc 707 Grant Street
412 338 4400 The Gulf Tower Pittsburgh 15219
