forced fsck (again?)

Andreas Dilger adilger at sun.com
Thu Jan 24 04:39:30 UTC 2008


On Jan 23, 2008  21:10 -0500, Bryan Kadzban wrote:
> Since the email address is not per-filesystem, it's fine by me to put it
> into a config file somewhere.  Forcing the interval to be global is
> probably also OK, although I wouldn't want to be forced to set the
> snapshot size globally.  I do think that fstab is the best place for
> per-filesystem options, though.
> 
> But it's not too difficult to parse out a custom SNAPSIZE option, and
> even have a DEFAULT_SNAPSIZE in the config file if no SNAPSIZE option is
> present on any LV, if the script is going to parse fstab anyway.  (Or
> should the option's name be lowercase?  Either will work.)

The problem with this is that ext2/3/4, along with most other filesystems
will fail to mount if passed an unknown mount option.

> Regarding the idea of having this support multiple filesystems -- that's
> a good idea, I think, but the current script is highly specific to ext2
> or ext3.  Use of tune2fs (to reset the last-check time) and dumpe2fs (to
> find the last-check time), in particular, will be problematic on other
> FSes.  I haven't done that in this script, though it may be possible.

Well, my equivalent script just checks for fsck.${fstype} and runs that
on the snapshot, if available.   Even if tune2fs isn't there to update
a "last checked" field, it is still a useful indication of the health
of the filesystem for a long-running system.  For filesystems like XFS
where fsck.xfs is (unfortunately) an empty shell that does nothing this
could be special-cased to call xfs_check.

> # parse up fstab
> grep -v '^#' /etc/fstab | grep -v '^$' | awk '$6!=0 {print $1,$3,$4;}' | \
> while read FS FSTYPE OPTIONS ; do

Urk, that is kind of ugly shell scripting...  Cleaner would be:

cat /etc/fstab | while read FS DEV FSTYPE OPTIONS DUMP PASS
	case $FS in
	"") continue ;;
	*#*) continue;;
	esac

But I've come to think that /etc/fstab is the wrong thing to use for
input.  This script is only useful for LVM volumes, so getting a list
of LVs is more appropriate I think.

> 	# get the volume group (or an error message)
> 	VG="`lvs --noheadings -o vg_name "$FS" 2>&1`"

Interesting, I wasn't aware of lvs...  It looks like "lvdisplay -C".

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.




More information about the Ext3-users mailing list