Red Hat Bugzilla – Bug 168472
RFE: auto fsck determination in the filesystem resource agent for ext3
Last modified: 2009-04-16 16:18:06 EDT
Description of problem:
Currently, the file system resource agent does not do any automatic fsck-ing of
ext3 file systems. This should be changed, possibly by adding an option
"auto_fsck" to the resource agent metadata. When set, we should automatically
fsck the file system when needed. This is different from the "force_fsck"
option which causes the file system to *always* be checked (and thus supersedes
So, in a short discussion, with sct and hgarcia, the filesystem resource agent
should check the following:
(1) Cleanliness state of the file system. This information is available from
the tune2fs command.
Filesystem state: clean
(When clean, no need to fsck)
(2) Mount count. If this is exceeded, we should fsck the file system. This
information is available via the tune2fs command.
Mount count: 23
Maximum mount count: -1
(-1 means "no max mount count); in this case, the check should be ignored.
(3) Last check time. If we've exceeded the check interval, we should fsck the
file system prior to mounting. This information is available via the tune2fs
command. This information, unfortunately, is in human-readable format.
(Bugzilla coming for integer format...) e.g.:
Last checked: Mon Jun 13 08:22:38 2005
Check interval: 0 (<none>)
(0 means no check interval; in this case, the interval should be ignored)
(4) Journal superblock state. If the journal is inconsistent, we should fsck as
well. This information is currently not available. Bugzilla coming.
Note that e2fsck will automatically check for everything except (4) (I think).
So, when auto_fsck is enabled, we can simply call "e2fsck" on the device. It
will honor the check intervals and mount counts.
It should check (4) too, though it doesn't seem to do so now -- I'll need to
speak to Ted about this!
fsck -p is done with the force_fsck option in rgmanager (odd; force_fsck should
be -fy, not -p, but it works, so we'll use it).
All we need is UI support and we're good, except for a corrupt journal... :)
This was actually in GA; we just need to add GUI support if we care about it.