gold@aecom.UUCP (Yosef Gold) (06/02/85)
Can anyone tell me what inode number 1 is? I know 2 is root, and 0 is
the superblock, but I can't figure out what 1 is.
Yosef Gold
--
Yosef Gold
...{philabs,cucard,pegasus,ihnp4,rocky2}!aecom!goldalan@drivax.UUCP (Alan Fargusson) (06/04/85)
> > Can anyone tell me what inode number 1 is? I know 2 is root, and 0 is > the superblock, but I can't figure out what 1 is. > > Yosef Gold > -- > Yosef Gold > ...{philabs,cucard,pegasus,ihnp4,rocky2}!aecom!gold Someone that worked at Bell Labs told me that some versions of UN*X used inode number 1 to hold the bad blocks on a disk. That way fsck(1m) didn't think that they were missing. -- Alan Fargusson. { ihnp4, amdahl, mot }!drivax!alan
lrr@gypsy.UUCP (06/05/85)
Inode number 1 is ``reserved'' and (to the best of my knowledge) it is not used. There is no inode 0. Inode 0 has special meaning, and that meaning is unused. Unused directory entries, for example, are those entries for which the inode number is 0. There is no inode number for the super block as it is not a file. Larry Rogers Siemens Research and Technology Laboratories Princeton, NJ 08540 princeton!siemens!jaguar!lrr 609 734 6559
guy@sun.uucp (Guy Harris) (06/06/85)
> Can anyone tell me what inode number 1 is? I know 2 is root, and 0 is > the superblock, but I can't figure out what 1 is. Inode 0 isn't the superblock; there is no inode 0 (some UNIX implementations have a slot 0 in the ilist, but it's unused). Inode 1 is the "bad-block" inode. If you look at the "mkfs" code, it was intended that when you built a file system you could specify a set of bad blocks. These would be the "data" blocks of inode 1; "dump" starts with inode 2, so it won't try to read the blocks of inode 1 (and get I/O errors). (This same idea appears in other file systems, like DEC's FILES-11.) However, the routine in "mkfs" which says whether a block is bad or not always says the block is good, so the bad block file is always zero-length. (Also, "fsck" would have to be taught that this file should not have any links to it, and that it shouldn't complain if it doesn't or make a link to it in lost+found.) Guy Harris
robert@cheviot.UUCP (Robert Stroud) (06/15/85)
In article <44700005@gypsy.UUCP> lrr@gypsy.UUCP writes: > >Inode number 1 is ``reserved'' and (to the best of my knowledge) it is not >used. > >Larry Rogers >Siemens Research and Technology Laboratories >princeton!siemens!jaguar!lrr On at least some European V7 systems, inode 1 is used for a list of bad blocks. Basically mkfs has been extended to include a secret undocumented option (in the true Unix tradition!) which scans the whole device and puts any funny blocks in inode 1 out of harms way. As far as I know, nothing else pays any attention to the list - it is just a device for keeping blocks off the free list without upsetting fsck. Such modified versions of mkfs take 5 arguments. The first two are as normal, the next two are the m/n ratio (something to do with the initial spacing of the free list I think), and the fifth indicates whether the bad block check is required. I have no idea whether this feature is standard (but undocumented), or a local hack, but I have seen it on more than one system. Robert Stroud, Computing Laboratory, University of Newcastle upon Tyne. UUCP ...!ukc!cheviot!robert ARPA robert%cheviot.newcastle@ucl-cs.ARPA
campbell@maynard.UUCP (Larry Campbell) (06/15/85)
> In article <44700005@gypsy.UUCP> lrr@gypsy.UUCP writes: > > > >Inode number 1 is ``reserved'' and (to the best of my knowledge) it is not > >used. > > > >Larry Rogers > > On at least some European V7 systems, inode 1 is used for a list of bad > blocks. Basically mkfs has been extended to include a secret undocumented > option (in the true Unix tradition!) which scans the whole device and puts > any funny blocks in inode 1 out of harms way. As far as I know, nothing else > pays any attention to the list - it is just a device for keeping blocks off > the free list without upsetting fsck. > > I have no idea whether this feature is standard (but undocumented), or a > local hack, but I have seen it on more than one system. > > Robert Stroud, VENIX/86 mkfs has a -b option, which the manual says "causes mkfs to check the disk for bad blocks (unreadable), to gather them together and put them in an inaccessible file." VENIX is a more-or-less vanilla Seventh Edition port, but this could be a local extension. (I've never seen it find a bad block, so I don't even know if this works.) - Larry Campbell The Boston Software Works, Inc., 120 Fulton St., Boston MA 02109 UUCP: {decvax, security, linus, mit-eddie}!genrad!enmasse!maynard!campbell ARPA: decvax!genrad!enmasse!maynard!campbell@DECWRL.ARPA
henry@utzoo.UUCP (Henry Spencer) (06/17/85)
> On at least some European V7 systems, inode 1 is used for a list of bad > blocks. Basically mkfs has been extended to include a secret undocumented > option (in the true Unix tradition!) which scans the whole device and puts > any funny blocks in inode 1 out of harms way. > ... > I have no idea whether this feature is standard (but undocumented), or a > local hack, but I have seen it on more than one system. It's sort of semi-standard. The original V7 had hooks in mkfs for putting a bad-block list in inode 1, but didn't bother actually doing it (the give-me-a-bad-block-number routine was a stub that always returned "none"). Many people have noticed this and extended mkfs, in one way or another, to actually install a bad-block list. > As far as I know, nothing else > pays any attention to the list - it is just a device for keeping blocks off > the free list without upsetting fsck. Actually, several other programs (e.g. dump and restor) needed slight fixes to make them keep their hands off inode 1, but these were pretty trivial. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry