forced fsck (again?)

[Bryan Kadzban]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

Andreas Dilger wrote:
> On Jan 25, 2008  21:02 -0500, Bryan Kadzban wrote:
>> logger $arg -p user."$sev" -- "$msg"
> 
> This should use "-t lvcheck" so that it reports what program is generating
> the message.

Yep, that'd be useful.

>> tune2fs -C 16000 -T "19000101" "$dev"
> 
> I'm a tiny bit reluctant to overwrite the "last checked" date, since this
> might be useful information for the administrator (i.e. it will tell the
> interval wherein the corruption was detected).  Setting the "mount count"
> is enough to force a check, and the mount count itself can be reverse
> engineered from "reboot" messages in the "last" log.

Assuming the user doesn't set a maximum mount count higher than 16000
(but I think that's highly unlikely).  I think the benefit of being able
to know (approximately) when corruption started is probably worth it,
though.

> It is a lot clearer if the "cases" (ext2|ext3|ext4) are aligned with the
> "case" statement,

I see what you mean.  The script just uses vim's default autoindent
levels, but I can change the cases.

>> reiserfs)
>> 	# do nothing?
> 
> I thought you were going to remove the empty reiserfs cases?

Er, I was; I think I was looking at the wrong case last time around.
This one's gone now as well.

>> local tmpfile=`mktemp -t e2fsck.log.XXXXXXXXXX`
> 
> Shouldn't be "e2fsck.log"?  Maybe "lvcheck.log.XXXXXXXXX"?

Yeah, that'd be better; that's more leftover code from the original script.

>> # Assume the script won't run more than one instance at a time?
>> lvremove -f "${lvtemp##/dev}"
> 
> Should check the error return and bail out of script if there is an error.

Will that catch the "more than one instance at a time" case (e.g. if
another script run is still running e2fsck on this snapshot)?  Assuming
lvremove can fail (and it probably can), it's probably a good idea to
check it in any case, but if running e2fsck makes lvremove fail (until
e2fsck finishes), that's a decent way to get rid of the comment too.

Also, I think it'd be better to skip just the current FS, rather than an
"exit 1" type bail-out, right?

> MINFREE=0	# megabytes to leave free in each volume group
> MINSNAP=256	# megabytes for minimum snapshot size.

I've added something very similar to this logic, but I changed the
checks around a bit.  I think it makes more sense this way (doing the
overall space check first, and then the limits second), unless this
logic disallows some valid combinations?

(Still trying to decide how to handle logging *fsck output, and what to
do with the file, based on your other message...)

- -----

Create a script to transparently run fsck in the background on any
active LVM logical volumes, as long as the machine is on AC power, and
that LV has been last checked more than a configurable number of days
ago.  Also create an optional configuration file to set various options
in the script.

Signed-Off-By: Bryan Kadzban <bryan at kadzban.is-a-geek.net>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHnnnRS5vET1Wea5wRAw0iAJ9wcLyfBSaH5FSIJNH0YakzDCUvjwCgnJEH
lPScP39vBYIIjOQPiftgDs8=
=XjFF
-----END PGP SIGNATURE-----
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: lvcheck
URL: <http://listman.redhat.com/archives/ext3-users/attachments/20080128/e606b548/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: lvcheck.conf
URL: <http://listman.redhat.com/archives/ext3-users/attachments/20080128/e606b548/attachment.conf>