Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!auspex!guy
From: guy@auspex.auspex.com (Guy Harris)
Newsgroups: comp.unix.wizards
Subject: Re: inode 1
Keywords: inode 1
Message-ID: <5569@auspex.auspex.com>
Date: 29 Jan 91 18:44:10 GMT
References: <2383@beguine.UUCP>
Organization: Auspex Systems, Santa Clara
Lines: 19

>Not knowing a lot about the implementation of inodes, I can only guess as to
>why inode 1 is empty and unnamed.  Sometimes, when people implement a linked 
>list or other related data types, they have a dummy header node to the list.
>What this does is eliminate the need of handling certain special cases when
>adding or deleting to or from the front of the list, which produces more 
>easily readable source code.  The overhead of one additional node is 
>negligible.  Maybe that's why the first inode is unamed and empty...

Nope.  This was discussed recently in "comp.unix", I think.  In V7, the
root inode was moved from inode 1 to inode 2; the intent was apparently
to have inode 1 be the "bad block file", to which all disk blocks
unusable due to medium errors would be assigned.  "mkfs" had a
half-implemented mechanism to do this; it would call a routine to ask if
a block is bad and, if so, assign that block to inode 1 - but the
routine never said the block was bad.  Some, perhaps all, utilities that
scanned the ilist would skip inode 1 for certain purposes.

The ilist wasn't a linked list in V7, so the dummy header node idea
doesn't apply.