[Pkg-sysvinit-devel] Bug#526398: /etc/init.d/checkroot.sh: can cause serious data corruption if booting on, battery power

[Zygo Blaxell]

On Fri, May 01, 2009 at 06:35:03PM +0100, peter green wrote:
> Would a compromise be possible? Something along the lines of doing  
> urgent stuff (journal replays, checks of unclean unjournaled  
> filesystems) but skipping the "n days/mounts since last check- check  
> forced" checks when on battery? Does fsck have and options that would  
> allow this or would they have to be added?

That would be nice, but out of scope of this bug.  I'd like the data-loss
issues fixed first, then worry about enhancing life for ext3 users with
disks that are too big for their batteries.  ;-)

AFAICT the exceptional case is ext3, because all the other filesystems
I've used on Linux either have journals (and they work, so they don't need
fsck), or they don't (so they do need fsck).  Only ext3 (or more precisely
e2fsck) has this strange mode where it does fsck's at random even though
it has no evidence to believe they're necessary.

A simple solution to the ext3-specific part of the problem
is to have the Debian installer use 'tune2fs -c0 -i0' after
'mke2fs -j' when installing on laptops.  This eliminates ext3's
fscking-at-random-and-inconvenient-times behavior.  Users who are
concerned about running fsck on battery power should be directed to
run this command, instead of breaking initscripts for everyone else.
This solution would be a bug for the installer and/or the documentation
of rcS, and implementing the ext3-specific solution doesn't remove the
need to fix this bug (#526398) on initscripts.

There are some valid points in the ext3 documentation about the need to
do fsck's at regular intervals to check for past failures to maintain
data integrity in the filesystem; however, those apply equally to all
filesystems, and arguably should be implemented by the initscripts for all
local read/write filesystem types that have fsck tools--not buried in the
ext3-specific tools themselves.  Also, fsck only makes the filesystem
usable to store new data--it doesn't restore any of the data you've
probably lost if your storage subsystem has these sorts of problems.
I don't think this is a problem that initscripts should try to solve
beyond alerting the user to the fact that their storage subsystem is
lossy and needs serious debugging.

Ideally there should be a fsck-detection tool (possibly a flag supported
by modified versions of the existing fsck tools) which can, given a
filesystem, tell initscripts which of three states the filesystem is in:

	1.  The filesystem is known to have errors, or lacks journalling
	and was not cleanly umounted, and *must* be checked.  When
	initscripts detects the machine is on battery power, it could
	prompt the user for various options:

		a.  check the filesystem and boot normally

		b.  power off immediately

		c.  (with root password) boot without checking filesystem

		d.  run sulogin

		e.  after a timeout, proceed with one of the above options
		chosen by a config file (e.g. /etc/default/rcS).

	2.  The filesystem is not known to have errors, but a policy
	limit (mount count or days since last fsck) has been reached.
	initscripts would not check the filesystem if on battery power
	in this case, based on the assumption that the user will reboot
	later on battery power to perform the advised fsck.

	3.  The filesystem is known to be cleanly umounted (or recoverable
	from journal) and no fsck is recommended.  initscripts may
	always run fsck in this case, since fsck should exit quickly
	(if it doesn't, that's either a bug in the fsck package or
	the fsck-detection tool).  Some filesystems may not be able
	to determine quickly if they were cleanly umounted, so maybe
	initscripts might skip fsck entirely for those filesystems.

Of course, if /fastboot or /forcefsck are present, initscripts would
honor those as it does now.

Note that the above proposal requires work to either modify the various
filesystem-specific fsck tools packages so that initscripts can use
them, or initscripts could implement the currently ext3-specific maximum
mounts/days behavior itself.  Both of those are wishlist items, but this
bug (#526398) is a critical bug.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-sysvinit-devel/attachments/20090501/36f785b0/attachment.pgp>