Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!mit-eddie!minya!jc
From: jc@minya.UUCP (John Chambers)
Newsgroups: comp.sys.att,comp.unix.wizards
Subject: Re: Wierd 3b inode problem with news.
Message-ID: <359@minya.UUCP>
Date: Wed, 11-Nov-87 08:03:29 EST
Article-I.D.: minya.359
Posted: Wed Nov 11 08:03:29 1987
Date-Received: Fri, 13-Nov-87 21:55:28 EST
References: <283@paisano.UUCP> <4259@sdcsvax.UCSD.EDU> <355@minya.UUCP> <33319@sun.uucp>
Organization: home
Lines: 28
Keywords: 3b2 inode file system
Xref: mnetor comp.sys.att:1722 comp.unix.wizards:5424

In article <33319@sun.uucp>, guy@gorodish.Sun.COM (Guy Harris) writes:
> > But in Sys/V, free inodes are also in a linked list, so the
> > kernel is dependent on inodes being freed properly.
> 
> In the V7 file system, which is used by S5, free inodes are not in any sort of
> linked list.  There is a cache in the superblock that saves the i-numbers of a
> small number of free inodes.  

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;
		cnt_t	i_count;	/* reference count */
		dev_t	i_dev;		/* device where inode resides */
		ino_t	i_number;	/* i number, 1-to-1 with device address */
	...

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.

Or am I misinterpreting something?

-- 
John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393)