All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Theodore Ts'o" <tytso@mit.edu>
To: Petr Vandrovec <VANDROVE@vc.cvut.cz>
Cc: Duncan Sands <baldrick@wanadoo.fr>,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	ext2-devel@lists.sourceforge.net, adilger@clusterfs.com
Subject: Re: [Ext2-devel] Re: Htree ate my hard drive, was: post-halloween 0.2
Date: Thu, 31 Oct 2002 17:03:36 -0500	[thread overview]
Message-ID: <20021031220335.GA9237@think.thunk.org> (raw)
In-Reply-To: <62C20ED5AAC@vcnet.vc.cvut.cz>

On Thu, Oct 31, 2002 at 01:19:23PM +0200, Petr Vandrovec wrote:
>     
> Nobody answered it at that time, and it happened at least 5 times
> again to me - until I modified initscripts to do unconditional
> reboot if "fsck /" did ANY modifications to filesystem.
> 

In fact, e2fsck should return an exit code which indicates that the
systme should be rebooted if an fsck the root filesystem makes any
changes to the filesystem.  See the man page to fsck(8) for a
definition of fsck's exit codes, but if (exit_status & 2) is non-zero,
the init scripts **should** reboot.  

Unfortunately, not all distributions get this right.  However, your
analysis is right.  If fsck needs to make any modifications to the
root filesystem, which is mounted read-only, it is possible for the
corrupted filesystem elements to still be cached in memory, and then
written back out to disk when the filesystem is remounted read/write.  

This is one reason why I normally recommend that / be a small
filesystem of approximately 128 megs, with separate partitions for
/usr, and either using a separate partition for /var, or using a
symlink from /usr/var to /var.  (And doing something similar for /home
and and /opt, as necessary.)  It minimizes the chances that the root
filesystem will get corrupted, and makes running fsck on the root
filesystem take much less time (obviously, since the root filesystem
becomes quite small.)

						- Ted

  parent reply	other threads:[~2002-10-31 21:57 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-31 11:19 Htree ate my hard drive, was: post-halloween 0.2 Petr Vandrovec
2002-10-31 21:42 ` [Ext2-devel] " chrisl
2002-10-31 22:03 ` Theodore Ts'o [this message]
  -- strict thread matches above, loose matches on Subject: below --
2002-10-30 17:11 Dave Jones
2002-10-31  6:27 ` Htree ate my hard drive, was: " Duncan Sands
2002-10-31  8:07   ` Andreas Dilger
2002-11-04 22:42     ` [Ext2-devel] " Stephen C. Tweedie
2002-11-04 22:59       ` Duncan Sands
2002-11-04 23:22       ` Udo A. Steinberg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20021031220335.GA9237@think.thunk.org \
    --to=tytso@mit.edu \
    --cc=VANDROVE@vc.cvut.cz \
    --cc=adilger@clusterfs.com \
    --cc=baldrick@wanadoo.fr \
    --cc=ext2-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.