Bugzilla Bug 116016

if you want to force a full fsck on boot /etc/init.s/checkroot and checkfs use
the option "-f". unfortunatelythis is ignored by reiserfs (since the full check
is reiserfsck's default behaviour). the option "-a", which also is always used
by bootscripts is interpreted by reiserfsck as: "these options cause reiserfsck
[...] to do some light-weight checks." long story short: in the moment there's
no way to perform a thorough fsck on reiserfs without booting from a cd. in my
opinion "shutdown -F" (forcefsck) should provide such a thorough fsck.

so i propose changing out bootscripts to provide a filesystem-dependent fsck.

in checkfs that would be replacing the line
    fsck -C -R -A -a -f
by the two lines
    fsck -C -R -A -a -f -t !reiserfs
    fsck -R -A -y -t reiserfs

in checkroot the line
    fsck -C -a -f /
will be replaced by
    fs_type=$(mount -f -n -v / | awk '{ print $5 }')
    if [ $fs_type == "reiserfs" ] ; then
        fsck -y /
    else
        fsck -C -a -f /
    fi

the only thing we lose is the parallel fsck of reiserfs and non-reiserfs
partitions in checkfs. in the future there can be added more
filesystem-dependant fsck-options if that's going to be necessary.

i'm quoting from baselayout-1.11.13-r1 and the applied patch is against that
version. the problem still exists with a newer version
(baselayout-1.12.0_pre11-r3) and if you like this approach i can adjust the
patch to that version.

Created an attachment (id=75072) [edit]
adds support for filesystem-dependant forcefsck-options

cant say i'm really keen on adding this at all

filesystem-dependent calls suck

well, i think we all prefer simpler scripts. in the end i see the problem of
not being able to do a proper reiserfs-check out of the box and changing the
bootscripts seemed the easiest solution for me. other approaches may be:
  1) replacing the symlink /sbin/fsck by a wrapper which tweaks the options,
e.g. removes "-a" from the option-list if "-f" is present
  2) waiting for/asking the reiserfsck-developers to support "-f"

actually i'm not really sure if all fsck.* really should support all the same
options, since checking depends a lot from the underlying filesystem and imho
each filesystem-developer should choose his own necessary options. from this
point of view the bootscript-approach seemed the most logic one.

(In reply to comment #2)
> cant say i'm really keen on adding this at all
> 
> filesystem-dependent calls suck
> 

I don't like this either.
Maybe patch reiserfsprogs ?

the sane thing here would probably be either:
 - have fsck remap options for reiserfs like it does with ext2
 - have change reiserfsck's behavior when given -a

The actual fix here is quite easy really :)

We should use the more friendly preen option -p instead of -a.
In my testing, all fsck helpers support (or work correctly with) -p, -f and -y
which are e2fsprogs, jfsutils, xfsprogs, reiserfsprogs. I've also made the
script a lot simpler by merging the BSD options in better.

You can see the new scripts here
http://sources.gentoo.org/viewcvs.py/baselayout/trunk/init.d/

-p isnt in fsck man page ;x

(In reply to comment #7)
> -p isnt in fsck man page ;x

Picking some nits here, but it's listed as under -a when it's remapped to -p
for e2fsck. However, the man page is wrong here as fsck itself does no such
thing. e2fsck maps -a to -p itself, and the other fsck helpers also support -p
which strangely enough so do the BSD userlands.

So I guess the man page is out dated or incorrect.

OK, it's a little more tricky.

reiserfs is the only helper that doesn't like -f
xfs doesn't work with fsck and it's helper just spits out a message about this
jfs -f doesn't work with -n (which is kinda daft)
e2fsck is the only helper which requires either -y or -n when using -f

So, the easiest solution is to patch jfsutils to allow -f -n and change
reiserfsprogs meaning of -n from --nolog to --no.

OR

We patch jfsutils -f "fix everything" to mean "-f -n" as above and patch e2fsck
(and busybox) to default to -n if no terminal (which it hasn't when in an init
script).

OR

We scrap the forcefsck on boot option in our init scripts.

Personally I'm in favour of the first option and will provide patches.

Created an attachment (id=117959) [edit]
jfs.patch

Created an attachment (id=117961) [edit]
reiserfs.patch

I saw the post on dev- and let me comment a bit.

To comment #10, comment #11:
Did you try to contact upstream with such patches?

They do seem trivial and logical to me, but patching something as basic as fsck
is wrong in the first time. Imagine the day everything is b0rked on a
"production" box and you are doing your best ('cause that box sysadmin is on
vacation) just to find out that fsck does not behave as the rest (pick a
distro) boxen....

Think again:

Problem: We (=Gentoo) are having problems unifying the boot scripts...

Solution A: fix/workaround/patch the boot-scripts
Solution B: fix "the root cause", patching the "wrong" fsck utils

Boot scripts are something Gentoo specific and although I'd hate them change
too often, I can live with it. My colleague, who is a (pick a distro) diehard
doesn't care probably. I don't care since once the box is up everything behaves
as expected.

Solution B is wrong since it fixes basic (i.e. all dsitros) commands to behave
differently, IMHO.

And if you (devs) decide to implement this, do put a big fat warning in the
manpage and --help like "***NB: Gentoo specific: bla-bla-bla ***"

Just my two yen.

(In reply to comment #12)
> To comment #10, comment #11:
> Did you try to contact upstream with such patches?

No, as we have not yet decided which course of action to take.

> They do seem trivial and logical to me, but patching something as basic as fsck
> is wrong in the first time. Imagine the day everything is b0rked on a
> "production" box and you are doing your best ('cause that box sysadmin is on
> vacation) just to find out that fsck does not behave as the rest (pick a
> distro) boxen....

We're not patching fsck - we're patching the fsck helpers. All fsck does is
pass cmdline options to the helpers ....

jfs patch submitted upstream
http://sourceforge.net/tracker/index.php?func=detail&aid=1758767&group_id=128802&atid=712756

Thanks for opening the jfs bug.  I'll fix the jfs piece upstream

OK, I've added these patches to portage as no-one seems they'll break anything.
jfs upstream has been notified (Hi Dave!)
and I've emailed the reiserfs mailing list with the attached patch, so we
should be golden now :)

This is now fixed in upstream - jfsutils-1.1.12

Works for me - thanks :)

What about fsck.reiser4?


The option -p just prints profile, so it has to be changed too.

That must have been a recent change as when I tested it supported -p just fine.
Open a new bug for that please.