forced fsck (again?)

[Bryan Kadzban]

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

Andreas Dilger wrote:
> On Jan 23, 2008  21:10 -0500, Bryan Kadzban wrote:
>> 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.

Uh oh.  Yeah, that's a problem.

I was under the impression that all the tools would ignore unknown
options -- if that's not the case, then we probably need to come up with
something else.  Automatically determining the snapshot size sounds like
a good idea, but I'm not sure how to do it.  (I'm not sure what decides
the snapshot size that you need -- it looks like the number of changes
that you're going to make to the snapshot, or maybe the number of
changes that you're going to make to both the snapshot and the real LV?
 In either case, I'm not sure how to find that out.  Maybe just using
"all available space in the VG" is a better idea anyway.)

>> 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.

True, but what about determining whether it has to run at all (based on
the last-check time)?  Although, 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.

Of course that means that if you can't update the last-checked time,
then it'll run a check every day after the interval passes (and the
machine is on AC).  Of course the current script will do that too, so at
least it isn't any worse there.

>> 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...

Yeah, no kidding.  I wanted to kill lines with fs_passno set to zero,
since I was already killing lines that were empty or comments.  I was
also afraid that sh would die if I gave "read" more variables than
arguments (which is why I wanted to filter out the comments), but doing
some testing shows that bash (at least) handles it OK.  So maybe a
normal read would work better.

Or maybe rewriting in C would work; then I could just use getmntent.
Although I'm not exactly a fan of writing something like this in C,
either; shell is more powerful, except for this "reading fstab" thing.

> 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.

True, except the no-LVs behavior of lvscan, lvs, and any of the other
tools that I was looking at yesterday is decidedly non-optimal.  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, on MD-raid, on DM-raid (I
was testing an initramfs setup's worst-case), so it has the LVM tools
and filesystems.  I'll see what's available there.

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.

>> # 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".

Sort of, although I'm not sure what -C does (it's not in my lvdisplay
manpage).  That manpage refers to lvs (saying "lvs provides considerably
more control over the output"), and that was what I was looking for.
It's fairly easy to get it to print just the VG or just the LV, which is
what I needed.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHmIJES5vET1Wea5wRA417AKDInHscG+5bta5gSiC2hJ3QKeN05ACgzeCQ
8Wpo9KPog+p1gZMzrgN+Yp8=
=XgD8
-----END PGP SIGNATURE-----