File system problems with 386/ix

Dwight Kelly dkelly at npiatl.UUCP
Sat Oct 14 05:43:49 AEST 1989


In article <2462 at hydra.gatech.EDU> gb7 at prism.gatech.EDU (Joe Bradley) writes:
>
>This made me suspicious about the integrity of my file system, so I manually
>invoked fsck. Well, it complained about a few things which I let it fix
>(see below). However, when I invoke fsck again, it again complains about
>the same things that it just supposedly fixed. Does anybody have any ideas?
>Shouldn't these problems be fixed after running fsck?
>
>
>  FREE INODE COUNT WRONG IN SUPERBLK
>  ** Phase 5 - Check Free List 
>  9003 BLK(S) MISSING
>  BAD FREE LIST


Under 2.0.?, Interactive's fast file system marks almost all inodes as free and 
keeps a true map of allocated inodes in memory.  This way a panic or powerdown 
will force fschk to rebuild the ENTIRE inode list, giving the very large amount 
of incorrectly free blocks.  This is mentioned in the 2.0 upgrade kit on page 5
of the Release notes

I quote: 

 The fsck file system check program may sometimes display alarming messages when 
 checking a file system that was mounted using FFS at the time of a system failure
 Note that these messages are no cause for alarm. 
 When the FFS mounts a file system and builds its internal bitmap, it deliberately 
 marks the free list to be almost empty, to make sure that fsck will have to
 rebuild it from scratch in the event of a crash. fsck will rebuild
 a perfectly good free list, even though it may complain that thousands
 of blocks are missing, and the FFS can then use this free list to 
 reconstruct its internal bitmap when the file system is mounted again.

Dwight Kelly
Network Publications, Inc.
Director R&D



More information about the Comp.unix.i386 mailing list