Debian – How to force fsck at every boot – all (relevant) filesystems

I was going to suggest hacking e2fsck to disable the specific checks for a last mount time or last write times in the future. These are defined in problem.c / problem.h, and used in super.c. But in looking, I discovered that E2fsprogs 1.41.10 adds a new option to /etc/e2fsck.conf called broken_system_clock. This seems to be exactly what you need, and since you're using Red Hat Enterprise Linux 6, you should have 1.41.12, which includes this option. From the man page:

   broken_system_clock
          The e2fsck(8) program has some hueristics that assume  that  the
          system clock is correct.  In addition, many system programs make
          similar assumptions.  For example, the UUID library  depends  on
          time  not going backwards in order for it to be able to make its
          guarantees about issuing universally unique ID’s.  Systems  with
          broken  system clocks, are well, broken.  However, broken system
          clocks, particularly in embedded systems, do exist.  E2fsck will
          attempt  to  use  hueristics to determine if the time can no tbe
          trusted; and to skip time-based checks if this is true.  If this
          boolean  is set to true, then e2fsck will always assume that the
          system clock can not be trusted.

Yes, the man page can't spell "heuristics". Oops. But presumably the code works anyway. :)

I'm answering this in the general context of "journalled filesystems".

I think that if you did a number of "unclean shutdowns" (by pulling the power cord or something) sooner or later you'd get to a filesystem state that would require fsck or the moral equivalent of fsck, xfs_repair. The ext4 fileystsm on my laptop for the most part just replays the journal on every reboot, clean shutdowns included, but every once in a while, it does a full-on fsck.

But ask yourself what "replaying the journal" accomplishes. Replaying a journal just ensures that the diskblocks of the rest of the fileystem match the ordering that the journal entries demand. Replaying a journal amounts to a small fsck, or to parts of a full on fsck.

I think there's some verbal sleight of hand going on: replaying a journal does part of what traditional fsck does, and xfs_repair is exactly what the same kind of program that e2fs.fsck (or any other filesystem's fsck) is. The XFS people just believed or their experience led them to not running xfs_repair on every boot, just to replaying the journal.