Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!uwvax!oddjob!gargoyle!ihnp4!cbosgd!mandrill!hal!ncoast!allbery
From: allbery@ncoast.UUCP (Brandon Allbery)
Newsgroups: comp.sys.att,comp.unix.wizards
Subject: Re: Wierd 3b inode problem with news.
Message-ID: <5666@ncoast.UUCP>
Date: Sun, 15-Nov-87 19:58:58 EST
Article-I.D.: ncoast.5666
Posted: Sun Nov 15 19:58:58 1987
Date-Received: Tue, 17-Nov-87 07:24:20 EST
References: <283@paisano.UUCP> <4259@sdcsvax.UCSD.EDU> <355@minya.UUCP> <33319@sun.uucp> <359@minya.UUCP>
Reply-To: allbery@ncoast.UUCP (Brandon Allbery)
Followup-To: comp.sys.att
Organization: Cleveland Public Access UN*X, Cleveland, Oh
Lines: 31
Xref: mnetor comp.sys.att:1774 comp.unix.wizards:5481

As quoted from <359@minya.UUCP> by jc@minya.UUCP (John Chambers):
+---------------
| Gee, when I look in /usr/include/sys/inode.h on this 5.2 system, I see:
| 
| 	struct	inode
| 	{
| 		struct inode *i_forw;	/* hash chain forw */
| 		struct inode *i_back;	/* hash chain back */
| 		char	i_flag;
| 
| It sure looks like someone is doing linked lists from a hash table.  This
| would explain how things could get lost, and why fsck would find them.  It
| would also explain why fask makes comments about inode lists.
+---------------

Sorry.  This is the in-memory copy of an inode; the linked list in question
is a linked list of inodes currently in memory.  Why would they be in memory?
For speed.  Why do they need speed?  Because they represent:

	* root directories of filesystems
	* "chroot" root directories
	* current directories
	* mount points
	* open files
	* saved-text and/or demand-paged executables currently in use

all of which are referenced constantly.
-- 
Brandon S. Allbery		      necntc!ncoast!allbery@harvard.harvard.edu
{hoptoad,harvard!necntc,{sun,cbosgd}!mandrill!hal,uunet!hnsurg3}!ncoast!allbery
			Moderator of comp.sources.misc