File system problems with 386/ix

[Brian R. Eckert]

In article <2462 at hydra.gatech.EDU> gb7 at prism.gatech.EDU (Joe Bradley) writes:
>I've started having problems creating tar archives of certain parts of
>my file system. It crashes and dumps core while in the middle of creating
>any archive. I'm running 386/ix v2.0.1.
>
>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?
>
> [ fsck output deleted ]

I will first ask you a question:  are you running fsck at a multi-user
run level (2 or 3)?

Fsck repairs the filesystem which requires it to wade through the super-block
(the first block of the filesystem... it serves as an index to all the parts
of the filesystem:  free list, inode table, etc., hence its name).

The super-block is kept in core and updated in RAM, not on the disk.  When
UNIX is multi-user,  the super-block is periodically written to disk to
attempt to keep in sync.  Therefore,  fsck does its thing repairing the
filesystem and adjusting the super-block on the disk (while a bad super-block
still resides in memory);  shortly after,  UNIX writes the (BAD) in core
super-block to disk and the super-block is now useless again.

You should ALWAYS run an fsck in single-user mode (system maintenance mode);
in single-user mode,  no periodic update is done to the disk version of the
super-block.  Note that the root filesystem will automatically be remounted
if the super-block is modified by fsck.  You also should not run fsck on any
mounted filesystems (root being the exception) as you will invalidate the in
core super-block if the disk version gets modified.

Some versions of fsck will sync the disk before it goes to work (i.e. it tells
UNIX to write the in core super-block to disk), thus back-to-back fsck's report
the same problem (in many cases) if done while the system is multi-user.  In
any event,  you should manually do a sync prior to fsck.  Something like:

	# sync;sync
	# fsck /dev/.......

should be adequate.

As an aside:  not too many versions of UNIX ago,  if fsck modified the
root super-block,  you needed to press reset or power-off / power-on
the system.