fwp1@CC.MsState.Edu (Frank Peters) (01/20/91)
In article <1991Jan19.123830.8859@micromuse.co.uk> peter@micromuse (Peter Galbavy) writes:
For a while now I have been trying to find out - for no good reason -
what inode 1 is reserved for in ATT SYSV. Whether the same is true for
other UN*X's I do not know, but whatever V.2 or V.3 release I have
seen, the root directory of a file system is always (as far as I have
seen) inode 2.
I remember finding a quote along the lines of 'inode 1 is reserved for
future use' in a manual somewhere.
Anyone out there know the reason ? And is it a good one ?
From the inode man page for SunOS 4.1:
The root inode is the root of the file system. Inode 0 can-
not be used for normal purposes and historically bad blocks
were linked to inode 1, thus the root inode is 2 (inode 1 is
no longer used for this purpose, however numerous dump tapes
make this assumption, so we are stuck with it). The
lost+found directory is given the next available inode when
it is initially created by mkfs(8).
Is backwards compatibility a good reason? Depends upon whether you
need it I guess.
FWP
--
--
Frank Peters Internet: fwp1@CC.MsState.Edu Bitnet: FWP1@MsState
Phone: (601)325-2942 FAX: (601)325-8921mike@bria.UUCP (Michael Stefanik) (01/20/91)
In article <1991Jan19.123830.8859@micromuse.co.uk> micromuse!peter (Peter Galbavy) writes: >For a while now I have been trying to find out - for no good reason - >what inode 1 is reserved for in ATT SYSV. Whether the same is true for >other UN*X's I do not know, but whatever V.2 or V.3 release I have >seen, the root directory of a file system is always (as far as I have >seen) inode 2. > >I remember finding a quote along the lines of 'inode 1 is reserved for >future use' in a manual somewhere. I've noticed this too ... my manual claims "The first inode (i-node 1) on every filesystem is unnamed and unused". I wonder why ... -- Michael Stefanik, Systems Engineer (JOAT), Briareus Corporation UUCP: ...!uunet!bria!mike -- technoignorami (tek'no-ig'no-ram`i) a group of individuals that are constantly found to be saying things like "Well, it works on my DOS machine ..."
jeff@onion.rain.com (Jeff Beadles) (01/21/91)
In <1991Jan19.123830.8859@micromuse.co.uk> micromuse!peter (Peter Galbavy) writes: >For a while now I have been trying to find out - for no good reason - >what inode 1 is reserved for in ATT SYSV. Whether the same is true for >other UN*X's I do not know, but whatever V.2 or V.3 release I have >seen, the root directory of a file system is always (as far as I have >seen) inode 2. Inode #1 was (a long time ago) a "file" that contained nothing but bad blocks. Most system's don't use this any more, but they still reserve the number. I'm sure that there's some brain damaged (;-) software out there that thinks that inodes start at #3. Yes, to the best of my knowledge, inode #2 is always the root of a mounted filesystem. (Inodes #'s are unique to each filesystem.) -Jeff -- Jeff Beadles jeff@onion.rain.com
gordon@sneaky.UUCP (Gordon Burditt) (01/23/91)
>>For a while now I have been trying to find out - for no good reason - >>what inode 1 is reserved for in ATT SYSV. Whether the same is true for >>other UN*X's I do not know, but whatever V.2 or V.3 release I have >>seen, the root directory of a file system is always (as far as I have >>seen) inode 2. > > My understanding of inode 1 was that in the days before disk controllers >routinely mapped bad sectors and avoided them, inode 1 was to be used to >allocate bad blocks to a a dummy file. I don't think anybody does this >anymore so inode 1 is not used for anything these days. I have used inode 1 for this purpose on occasion. It's convenient at least as a stopgap and to get rid of marginally-faulty blocks that the format program doesn't consider bad but keep causing trouble. Programs that scan inodes such as dump/restor, quot, etc. start at inode 2 so the "file" with the bad blocks isn't dumped. Fsck starts at inode 1 for determining whether or not blocks are allocated to an inode, but at inode 2 for reporting on orphaned files. Gordon L. Burditt sneaky.lonestar.org!gordon
rick@uunet.uu.net (Rick Adams) (01/29/91)
From an old mail conversation. "Guy" is Guy Harris. From research!dmr Sun Mar 1 18:40:52 1987 Date: Sun, 1 Mar 87 18:40:40 EST From: research!dmr Message-Id: <8703012340.AA08897@seismo.CSS.GOV> Subject: inumerology Apparently-To: rick Status: RO Yes, v6 and previous had the root with i# 1, and v7 changed it to 2. There were two reasons for the change: first, as Guy thought, there was an idea of hiding bad blocks in the inode-1 file. Since we never did that, a possibly stronger motivation was just to prove that the system and the software were parameterized well enough to make it possible to change. Incidentally, years later I finally wrote a simple program that hid bad blocks. It doesn't use inode 1, though; you hand it the name of an existing, empty file and a list of blocks, and it fiddles the inode of the named file to put the blocks in it. Now we tend to use disks with ECC and automatic revectoring, but it still gets dusted off once in a while.
ghr@hpfcdj.HP.COM (George Robbert) (02/05/91)
/ hpfcdj:comp.unix.wizards / fwp1@CC.MsState.Edu (Frank Peters) / 4:35 pm Jan 19, 1991 /
In article <1991Jan19.123830.8859@micromuse.co.uk> peter@micromuse (Peter Galbavy) writes:
For a while now I have been trying to find out - for no good reason -
what inode 1 is reserved for in ATT SYSV. Whether the same is true for
other UN*X's I do not know, but whatever V.2 or V.3 release I have
seen, the root directory of a file system is always (as far as I have
seen) inode 2.
I remember finding a quote along the lines of 'inode 1 is reserved for
future use' in a manual somewhere.
Anyone out there know the reason ? And is it a good one ?
From the inode man page for SunOS 4.1:
The root inode is the root of the file system. Inode 0 can-
not be used for normal purposes and historically bad blocks
were linked to inode 1, thus the root inode is 2 (inode 1 is
no longer used for this purpose, however numerous dump tapes
make this assumption, so we are stuck with it). The
lost+found directory is given the next available inode when
it is initially created by mkfs(8).
Is backwards compatibility a good reason? Depends upon whether you
need it I guess.
FWP
--
--
Frank Peters Internet: fwp1@CC.MsState.Edu Bitnet: FWP1@MsState
Phone: (601)325-2942 FAX: (601)325-8921
----------