Hi!
Looking into the Filesystem RA of SLES11 SP1, I'm wondering:
Previously I found out that the RA happily mounts a filesystem with errors. Now
I found out that the RA can check the filesystems "automatically" (default).
Looking how it works makes me woner:
is_fsck_needed() {
case $OCF_RESKEY_run_fsck in
force) true;;
no) false;;
""|auto)
case $FSTYPE in
ext4|ext4dev|ext3|reiserfs|reiser4|nss|xfs|jfs|vfat|fat|nfs\
|cifs|smbfs|ocfs2|gfs2|none|lustre)
false;;
*)
true;;
esac;;
*)
ocf_log warn "Invalid parameter value for fsck: '$OCF_RESKEY_ru\
n_fsck'; setting to 'auto'"
OCF_RESKEY_run_fsck="auto"
is_fsck_needed;;
esac
}
So a filesystem is checked if it's "force-d", it's not tchecked if you say
"no", and in the "auto" case it's not checked if it's a well-known filesystem!
???
So you are saying those filesystems listed never have errors?
I'd agree on "nfs", "cifs", "smbfs" and "none", because it does not make sense
to check those, but for the ext3 case I'm wondering quite a lot.
I'm surprised about those design decisions. From tune2fs:
You should strongly consider the consequences of disabling
mount-count-dependent checking entirely. Bad disk drives,
cables, memory, and kernel bugs could all corrupt a filesystem
without marking the filesystem dirty or in error. If you are
using journaling on your filesystem, your filesystem will never
be marked dirty, so it will not normally be checked. A filesys-
tem error detected by the kernel will still force an fsck on the
next reboot, but it may already be too late to prevent data loss
at that point.
Note that with the Filesystem RA, the filesystem will _never_ be checked
(ignoring the settings)!
(Recently I got a report from a consultant that stated that it's not possible
with pacemaker to implement a "light out" functionality (probably meaning that
the cluster can reliably manage system faults). Looking at various
implementations details and omissions, I must agree that he's right. Probably
it's time to update the documentation.)
Regards
Ulrich
_______________________________________________
Linux-HA mailing list
[email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems
