forced fsck (again?)

Bryan Kadzban bryan at kadzban.is-a-geek.net
Fri Jan 25 03:20:04 UTC 2008


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

Bryan Kadzban wrote:
> Maybe just using "all available space in the VG" is a better idea
> anyway.

That's what I did here, at least for now.  There's a place in here where
the available space in the VG can be checked, but I'm not sure how to
get that value out of lvs (or vgs) in a format that's easy to parse, so
I skipped it for now as well.  (I could only get values like "250m",
which I assume means 250 megs, but how is the script supposed to handle
the suffixes?)

> I suppose it would work to leave the check interval set in the
> superblock, and avoid using fsck.* -f; that way each fsck would be
> able to determine if it should do a full check or not.

Turns out that will *not* work.  fsck.* without -f will succeed even if
it doesn't check anything (or at least, e2fsck will).  So every day, the
last-check day will get bumped, even though nothing actually got
checked.  That defeats the purpose here.

I've split out the operations of checking the FS, setting the last-check
time to now, setting the last-check time to some time in the ancient
past (if the check fails -- this forces the next-reboot check to be a
full one), and getting the last-check time, into their own functions.
Each one takes a device name and filesystem type argument, and splits
execution paths depending on the FS type.  Adding support for a new FS
(e.g. better support for reiser) should be as easy as modifying the case
statements in four functions.

> It would probably be possible; I'll see what I can find out later
> today.  I have a QEMU VM set up whose root FS is on LVM...

Well, it was set up.  I seem to have somehow nuked the md-raid layer, so
the LVM stuff isn't available anymore.  (It involved a qemu bug (the VM
was running, and suddenly died); then when starting it back up, the
md-raid code started a "background rebuild", and ended up locking up
qemu.  I'll probably have to start over with a new set of image files.)

> We'd still need to find the FS type, although I believe udev provides
> some programs that may be helpful (if we want to rely on them being 
> installed).  volume_id, in particular, should provide that info.

I'm running /lib/udev/vol_id here to get the FS type.  I'm not sure if
that's the best solution or not, but it does work (at least for now).

Anyway, I've also renamed the script from e2check to lvcheck (since it
works for more than ext* now).  Same changelog entry as before, though.

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

iD8DBQFHmVVjS5vET1Wea5wRA6sLAJ472TUX1amJroWIxdGbqQqlLZrS2QCeLHAA
z/fhwCISV3krc/coAmfWlVw=
=5gFW
-----END PGP SIGNATURE-----
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: lvcheck
URL: <http://listman.redhat.com/archives/ext3-users/attachments/20080124/17f705a7/attachment.ksh>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: lvcheck.conf
URL: <http://listman.redhat.com/archives/ext3-users/attachments/20080124/17f705a7/attachment.conf>


More information about the Ext3-users mailing list