home *** CD-ROM | disk | FTP | other *** search
/ ftp.cse.unsw.edu.au / 2014.06.ftp.cse.unsw.edu.au.tar / ftp.cse.unsw.edu.au / pub / doc / misc / apollo / hint_file < prev    next >
Encoding:
Internet Message Format  |  1992-10-18  |  2.8 KB
  1. Path: usage.csd.unsw.oz.au!metro!munnari.oz.au!samsung!umich!terminator!dabo.citi.umich.edu!rees
  2. From: rees@dabo.citi.umich.edu (Jim Rees)
  3. Newsgroups: comp.sys.apollo
  4. Subject: Re: mysterious hint file on HP/Domain/OS
  5. Keywords: hint
  6. Message-ID: <50cad431.cb12@dabo.citi.umich.edu>
  7. Date: 5 Apr 91 14:32:14 GMT
  8. References: <885@imec.UUCP>
  9. Sender: usenet@terminator.cc.umich.edu (usenet news)
  10. Reply-To: rees@citi.umich.edu (Jim Rees)
  11. Organization: University of Michigan IFS Project
  12. Lines: 41
  13.  
  14. In article <885@imec.UUCP>, fleureck@imec.be (Marc Fleureck) writes:
  15.  
  16.   On Domain/OS SR10.2 some machines seem to have a problem with the file 
  17.   /sys/node_data/hint_file.  For example, if I log out ( under DM ) on the 
  18.   machine itself, then go home to drink a cup of coffee and come back, 
  19.   I MIGHT be able to login again because the DM does not yet display its 
  20.   login pad.  In short, logout is terribly SLOW.
  21.   Solution : remove the hint file and reboot the machine.
  22.  
  23. When you want to open a file, Domain/OS first translates the name into a uid
  24. (like a dev/inode).  Then it has to locate the node holding that object.  In
  25. the old, old days, that was easy, because the uid contains the node id of
  26. the node on which it was generated.
  27.  
  28. Then removable (floppy) disks came along, and it got harder.  Now you could
  29. create a disk on one node, then mount it on another.  To find the objects on
  30. that disk you have to go to a different node from the one identified in the
  31. object uid.  Fortunately, the only way to get an object uid (usually) is by
  32. resolving a name, and when you resolve a name you start at a known place and
  33. work your way down, accumulating location information as you go.  Domain/OS
  34. caches this location information in the hint_file so that when you go to
  35. open (map) the object, it can be found.
  36.  
  37. Then internets came along, and it got way harder.  Now the hint file had to
  38. be changed to hold network numbers as well as node ids.  The bad news is
  39. that the hint file doesn't get flushed when it should, and stale information
  40. is sometimes used after a floppy changes nodes or a node changes networks.
  41. In general, you need to remove all hint files and reboot all nodes whenever
  42. a node moves from one network to another, or net numbers change.
  43.  
  44. Things become slow because when Domain/OS has to try a remote network to
  45. locate an object, it doesn't get a nack as it does on the local network.
  46. Instead it has to time out.  If it has to time out several remote networks,
  47. it can take a long time.
  48.  
  49. The hint file code is old and crufty and probably could use some work.
  50.  
  51. If you find that you have to remove the hint file at times when you haven't
  52. changed your network topology, then something else may be wrong.  Check to
  53. see that your nodes are cataloged correctly, with the right net id, in the
  54. network root name server.
  55.