Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!apollo!ced
From: ced@apollo.HP.COM (Carl Davidson)
Newsgroups: comp.sys.apollo
Subject: Re: mysterious hint file on HP/Domain/OS
Message-ID: <50e08e08.20b6d@apollo.HP.COM>
Date: 9 Apr 91 22:00 GMT
References: <50cad431.cb12@dabo.citi.umich.edu>
Sender: root@apollo.HP.COM
Lines: 64

From article <50cad431.cb12@dabo.citi.umich.edu>, by rees@dabo.citi.umich.edu (Jim Rees):
> 
> When you want to open a file, Domain/OS first translates the name into a uid
> (like a dev/inode).  Then it has to locate the node holding that object.  In
> the old, old days, that was easy, because the uid contains the node id of
> the node on which it was generated.
> 

It still does.

>
> [deleted description of how uids are used to locate files]
>
> Then internets came along, and it got way harder.  Now the hint file had to
> be changed to hold network numbers as well as node ids.  The bad news is
> that the hint file doesn't get flushed when it should, and stale information
> is sometimes used after a floppy changes nodes or a node changes networks.
> In general, you need to remove all hint files and reboot all nodes whenever
> a node moves from one network to another, or net numbers change.
>

The real culprit here, at least as of SR10.*, is the VM system, which 
caches Internet addresses in the object tables. Although the hint file
is updated by recataloging the node, the object tables in memory on the 
nodes which *weren't* moved still retain the old Internet address of the 
node and name resolution relies in part on these tables. The only way to 
purge the VM tables was to reboot the node, which, as Jim rightly indicates,
means potentially having to reboot every other node in an Internet. Not 
a pretty thought (we have over 2000 nodes here in Chelmsford). This has 
been changed in SR10.4, which will be released later this year (apply 
the usual disclaimers here). 

At SR10.4, the VM system is smart enough to time out stale Internet addresses
in its' tables. This should make moving nodes within an Internet 
easier. Also, SR10.4 automatically creates a new hint file when you reboot
a machine, so stale hints are even less likely to hang around.

> 
> Things become slow because when Domain/OS has to try a remote network to
> locate an object, it doesn't get a nack as it does on the local network.
> Instead it has to time out.  If it has to time out several remote networks,
> it can take a long time.
> 

Some of the timeout code was revised at SR10.4 also. Hopefully, it will
help some.

>
> The hint file code is old and crufty and probably could use some work.
> 

As of SR10.3 the hint manager keeps hints in "lru" order and is less
likely to throw away good hints and keep bad ones. Also, a lot of what
gets blamed on the hint manager is really caused by other parts of the
system. I know this because I used to blame a lot of what got fixed in
the VM subsystem on the hint file until looking closely at the problem.
(No, I'm not the person who fixed the VM system, but I am the one who 
complained until it was fixed :-))

 
Carl Davidson  (508) 256-6600 x4361    | 
The Apollo Systems Divison of          |  It doesn't TAKE all kinds,
The Hewlett-Packard Company            |  there just ARE  all kinds.
DOMAIN: ced@apollo.HP.COM              |