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