Bug 168468 - RFE: journal information information from tune2fs
RFE: journal information information from tune2fs
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: e2fsprogs (Show other bugs)
4.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Eric Sandeen
Jay Turner
:
Depends On:
Blocks: 168472
  Show dependency treegraph
 
Reported: 2005-09-16 11:03 EDT by Lon Hohberger
Modified: 2015-01-07 19:10 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-05-16 12:01:42 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Lon Hohberger 2005-09-16 11:03:14 EDT
Description of problem:

It may be useful to be able to print out the state of the journal superblock in
order to make a determination about whether or not to fsck the file system (or
repair the journal itself).
Comment 2 Stephen Tweedie 2005-09-16 11:19:17 EDT
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?
Comment 3 Stephen Tweedie 2005-09-16 11:26:36 EDT
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.
Comment 4 Lon Hohberger 2005-09-16 12:00:09 EDT
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.
Comment 5 Lon Hohberger 2005-09-16 12:11:12 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.