Re: [Ext2-devel] Re: Kernel 2.6.6: Removing the last large file does not reset filesystem properties

[Theodore Ts'o]

On Tue, May 11, 2004 at 11:32:26AM -0400, Valdis.Kletnieks@xxxxxx wrote:
> > I know what's happening and how to patch the initscript to get an
> > automatic reboot on exit code 2. Is that the proper way to handle it?
> 
> NO.
> 

YES.

Well, actially, the initscripts should reboot if the ((status & 2) != 0).
Or more simply, if the exit status is 2 or 3.

> Consider - if you *do* scrog your filesystem, you'll get hung in a loop
> of fsck/reboot/fsck/reboot/fsck/reboot.  You really *do* want the system
> to yell for help from a human at that point....

This is not a problem.  E2fsck only returns an exit status of 2 or 3
when it was able to cleanup the filesystem on its own.  The "reboot
requested" bit just means that the root filesystem was modified, and
there was no guarantees that the kernel might have cached information
which might get flushed to disk when the filesystem is remounted
read-write.  Hence, the need for a reboot.

Yes, this might seem a little Windows-esque, but for people who are
careful to keep their root partitions small (say, around 128 megs or
so), and use separate partitions for /usr and /var, this isn't a
problem.  For people who do use a single massive root filesystem, then
the need to reboot after e2fsck does a "preen" operation becomes more
common (although with ext3, this will rarely come up).  

The need to reboot could be removed if the remount of the read-only
filesystem to be read-write also caused the kernel to flush all state
and force everything to be reread from disk.  But this means flushing
all dentries, including possiblies dentries in use, and this was
ultimately decided to be Too Hard, and the idea was shot down by the
Grand Penguin himself.  

As far as your concern about infinite loops of
fsck/reboot/fsck/reboot, it isn't an issue.  If the filesystem is
actually massively scrod, to the point where human assistance is
necessary, then e2fsck will return an exit code of 4:

            4    - File system errors left uncorrected

Which should cause the initscripts to call for help.  An exit code of
2 or 3 merely means that the fsck is doing just fine, thank you very
much, and just needs a reboot in order to flush the disk caches.

						- Ted

P.S.  The real right answer is that the fsck of the root partition
should take place *before* the root partition is mounted, in the
initial ramdisk.  This gets rid of the whole need to flush the system
caches, since the (real) root filesystem isn't mounted at all during
the time of the initial check.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/