Re: Bootstrapping NFS

[barmar@Think.COM (Barry Margolin)]

    Date: Fri, 13 Sep 1991 18:04 EDT
    From: "Eric Mays" <emays@watson.ibm.com>

    >> Date: Fri, 13 Sep 1991 15:44-0400
    >> From: barmar@Think.COM (Barry Margolin)
    >>
    >>     Date: Fri, 13 Sep 1991 15:41 EDT
    >>     From: emays@watson.ibm.com (Eric Mays)
    >>
    >>     We just did this about two weeks ago (except out NFS host is an AIX
    >>     RS6000). We keep a small LMFS on an XL which is the nameserver. That
    >>     LMFS holds sys;site, sys;ip-tcp, sys:nfs, and sys:embedding;rpc. This
    >>     is described in the 8.1 install doc.
    >>
    >>     There is a minor glitch, and that is that you need a patch from
    >>     Symbolics in order to get the translations to go OK, and you also
    >>     need to eval (sct:reload-logical-pathnames-translation-files)
    >>     EACH time you boot. It's in our lispm-init.
    >>
    >> You shouldn't need to do this every time you boot.  I do it right after
    >> loading the NFS system, before loading other systems (which live on the
    >> NFS server).
    Almost all boots require loading some systems of the NFS server, thus
    it's in the lispm-init. Another customer has reported this
    difficulty as well.

We access NFS servers while booting (we load various initialization
files and load patches from the :WARM initialization list), but don't
have to reload the translations file each time (we reload translations
files that have changed since the world was saved, though).

The reason you need to reload the translations file after loading NFS
Client is that NFS modifies the way Unix pathnames are parsed, to turn
on the support for version numbers in ".sct" pathnames.  The Unix
pathnames in the translations were originally parsed in the old way, so
it has to be reloaded to force them to be reparsed.

But once this is done and saved away in the band, you shouldn't need to
do it again.

    >>     One other nasty is that the NFS connection dies at regular intervals
    >>     throughout the day for us and this requires a :reset net. I have not
    >>     yet heard from Symbolics as to whether this problem is theirs or not.
    >>
    >> I've been using Lispm NFS for years and don't recognize this problem.
    The error condition is that the "net is unreachable", our NFS server is
    on a different subnet from the LIspms, which could be the cause of
    the problem.

Many of our file servers are on different subnets from our Lispms, but
we rarely see this (I was seeing it for a while when we changed the
subnet that our Lispms live on, but continued to run bands that were
built before the change -- the code that accesses file servers while
booting would run before routing was fully reinitialized).

If it happens after the Lispm has been up and communicating successfully
for a while, it could mean that the Lispm has lost contact with the
router to that subnet.  Go into Peek Network and click on "Subnet
Routing", and if the router for the file server's subnet is listed as
"Dead" it means that the router didn't respond to the Lispm's periodic
pings.  Other than hardware problems, I'm at a loss to explain why the
Lispms would randomly lose contact with the server, though.

                                                barmar