What would be the problem with simply running fsck *anyway*?  Do you need to
know beforehand whether or not the full fsck is going to be required?

Another possibility --- would it be better to have e2fsprogs explicitly tell you
whether recovery, or full fsck, is required, rather than trying to work it out
yourself from tune2fs output?  For example, it would be possible to have a fsck
-q "query" option which asks if fsck is needed and returns the result as an RC code.

Running "e2fsck <dev>" checks if any of the obvious criteria are met (unclean
fs, max mount count exceeded, time-since-last-check > interval), but it'd be
nice to be able to add intelligence about it -- which would require knowing the
data ahead of time.

One-shot querying would make life easier, esp. since we'd have to parse nasty
human readable dates if we use tune2fs output... :)  Also, the query option
could also check the state journal superblock and take that into account (I
don't know if e2fsck does this or not?)

Another point - being able to display the contents of the journal superblock is
not a bad thing generally.  It's useful in much the same way as "tune2fs -l" is
useful.

As an example, our file system resource agent, we could check to see if the file
system should be checked, report that information, and only actually fsck the
file system in the case that the administrator *wants* us to fsck it.

In some conditions, of course, we should fsck regardless of the configuration
setting.  For instance, if the fs *needs* a full recovery, we should always
fsck, but if, say the mount count or interval was exceeded, we only need to fsck
if we're configured to do so.  (But always report in the system logs, in any
case...)

The counter to this, of course, is to always fsck when the query thinks we
should, and have the administrator use tune2fs to disable time
interval/mount-count based fsck runs.