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 attachment 75072 [details, diff] 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 attachment 117959 [details, diff] jfs.patch
Created attachment 117961 [details, diff] 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.
