[1273] in testers
Re: rt 7.2B: /srvd/patch
daemon@ATHENA.MIT.EDU (daemon@ATHENA.MIT.EDU)
Fri Nov 30 15:29:38 1990
Date: Fri, 30 Nov 90 15:29:01 -0500
To: "Jonathan I. Kamens" <jik@pit-manager.MIT.EDU>
Cc: testers@MIT.EDU
In-Reply-To: Jonathan I. Kamens's message of Fri, 30 Nov 90 12:17:40 -0500,
From: Richard Basch <probe@MIT.EDU>
Date: Fri, 30 Nov 90 12:17:40 -0500
From: "Jonathan I. Kamens" <jik@pit-manager.MIT.EDU>
Sender: jik@pit-manager.MIT.EDU
System name: pit-manager
Type and version: RTPC-ROMPC 7.2B
Display type: apa16
megapel
What were you trying to do?
Check if 7.2's /srvd/patch points to a useful location.
What's wrong:
It points to /patch.
What should have happened:
Well, first of all, /patch is completely the wrong place to
point it to, as far as I can tell. Second, it should point to
somewhere in AFS, since having it be a directory is no more
useful to us than not having it there at all, now that we only
have one system pack. I would recommend something like
/afs/athena.mit.edu/system/@sys/patch.
Please describe any relevant documentation references:
N/A.
jik
We can't rely on @sys, even if we do rely on AFS. For one, we already
have a dependence on AFS, which means that every system must either
mount it directly or via the AFS-NFS translator (in which case @sys
won't work).
By having it point to /patch (/mit/patch is already taken since there
seems to be a user "patch"), we can later decide whether to make an AFS
filesystem or simply a local NFS filesystem that mounts there (depending
on the architecture, as well as the machine). In 7.2, we also have
support for "multiple" attach's (type MUL filesystems), thus allowing us
to perform tricks like that.
What is more likely, if we need extensive changes, is to mount the big
/srvd elsewhere, with a smaller patched srvd and symlink farms to the
large one. Of course, if we were just supplying one or two new
"binaries" only, we could always make a simple "patch" filesystem.
The main purpose of having it point to /patch was to avoid committing
ourselves to something we may regret later. As I said, /patch might be
an "AFS" filesystem that makes it into a symlink to /afs. The reason we
do have to change it from a directory to a symlink is that we can't
mount directories over /afs (at least not safely), and AFS system packs
would then have to be different, if we kept the old method.
-Richard
