Best use of e2fsck

About USB hard drives and errors
From: Paul E Condon (resent from debian-user@lists.debian.org)
To: debian-user@lists.debian.org
Date: Fri Apr 9 08:44:33 2010

e2fsck -c is supposed to scan for bad blocks and allocate them
to a special inode so that they cannot be used. It runs for 3 to 4
hours and then says its finished with no indication of how many bad
blocks it found.

dumpe2fs -b is supposed to print the bad blocks that have
been marked on a device. When I run it, it prints nothing. I find it
hard to believe that a 500GB HD contains ZERO bad blocks. Especially
one on which I have witnessed error messages about I/O errors in
writing the journal. I can find no information about what, exactly,
dumpe2fs is supposed to print. The wording seems to be that it prints
the contents of the bad blocks. But in other places it seems that it
prints a list of block numbers, or maybe cylinder/sector/head. Since I
see nothing, I don't have a clue as to what I should see.

Has anyone ever used these programs? Have you ever seen useful output?
What SHOULD they do (with a little more specificity and believability)?

quotes from:
Re: Squeeze Gnome Preferences >> Removable Drives and Media
To: debian-user@lists.debian.org
Date: Sat Mar 27 11:23:51 2010

I think that the fs does the incrementing of the count. But when the limit is
reached, how is the execution of fsck started? What software does that? From
what running daemon is the job spawned? I have several HD for which limit is
set at under 30 but the actual count is over 50. How does that happen?

I didn't do anything to force this situation. I just plugged and played.
I'm suggesting that maybe there is a flaw in the design. Maybe something
was left out of consideration --- maybe.

-

If fstab's 6th column is 0, the mount count is not checked.

-

For the USB drives in question, there is no entry in /etc/fstab.

Assigning zero in cases where there is no entry in /etc/fstab is easy
to implement, but --- I wonder if it is good design, given that the
whole purpose of GUI interfaces is to make computing easy (and safe)
for naive users.

-

Of course, yes! I forgot about that. In the environment that I work in,
dynamic mounts of disk partitions are rare. They are almost always
mounted at boot time due to an entry in /etc/fstab. And that is where
the mount count is checked, due to a non-zero value in the sixth column,
and if it exceeds the filesystem-specified maximum, a check is forced
at that time. But if all mounts are dynamic, a check is never forced!

I checked the mount options to see if a mount option could force a check,
but the closest I came was

check={none,nocheck}
No checking is done at mount time. This is the default.
This is fast. It is wise to invoke e2fsck(8) every now and
then, e.g. at boot time.

(This is from "man mount".)

Unfortunately, since "none" and "nocheck" appear to be the only valid
sub-options for the "check" option, and since it is the default, there
does not appear to be any way to override it. Maybe there is an
undocumented option, like "check=whendue", or something like that, that
can be set with tune2fs, but barring that I can't think of a way to
force a check when a check is due, other than mounting it at boot time
via /etc/fstab and specifying a non-zero value in the sixth column.

-

But the actual check is done by *.fsck, which is not invoked by mount,
but by the initscript that invokes mount (if everything is ok). I wonder
if mount even contains the code to do filesystem checking at all[1].

What I'm trying to say is that this problem is not solvable at the
kernel/mount level, but by the userland tools doing the actual mount.

[1] I doubt it since it would have to include code for every mountable
filesystem, and this goes against the "do one thing and do it well"
philosophy.

-