[gentoo-amd64] Re: Disable fsck on boot, was: How to make watchdog start earlier during bootup?

[Duncan]

Beso <givemesugarr@×××××.com> posted
d257c3560901180446k7ffd4a6bv2077b53614fe7ba8@××××××××××.com, excerpted
below, on  Sun, 18 Jan 2009 13:46:14 +0100:

> i'd like to know if there's something particular to be aware of
> disabling fsck on boot with reiserfs and if there are some other
> things than removing the service from boot runlevel to be aware of.

Well, removing the service doesn't really work all that well, since it's 
a core service that's considered vital under normal circumstances, and a 
dependency of other services.  At least it didn't work well for me with 
baselayout2/openrc.  Maybe with old baselayout1 it can work without 
jumping thru all sorts of hoops to get and keep it off.

Instead, as the original post mentioning it indicated, the trick is to 
set the fstab entries to turn off fsck for whatever you don't want it 
regularly run on, in this case, reiserfs.  fsck order is the sixth field 
of an fstab entry.  Just set it to zero, and the fsck initscripts should 
ignore it.  (IIRC there was a fix for that on baselayout2 awhile back.  
I'm not sure if the fix was from baselayout1 or from earlier 
baselayout2s, however.  If it doesn't work, you need to update or try 
something else.)

> i'm using reiserfs v3.6 revision, r5 hash with ordered data and
> sometimes i have lockups that force me for unsafe resumes. can this
> trigger the need for a rebuild tree?

That's what I'm using; it's what I've used since well before data=ordered 
(except for the ordered data bit, which was from then, of course), and as 
I said, I haven't had problems with it, including no --rebuild-trees.  
This time without filesystem issues includes the couple years or so after 
I first got this machine, when it had bad memory and therefore lockup 
wasn't infrequent at all.  It also includes the period I was running a 
still unstable xorg composite, which ate memory and would sometimes crash 
the system that way.  And it includes various power outages due to 
thunderstorms or someone hitting a power pole or the like (a cat in the 
substation once...).  This area doesn't have too bad a power, but it's 
not perfect and I don't have a UPS.  (I could probably get one now that 
I've switched to LCDs, but the one I tried when I had CRTs was pretty 
high capacity and pretty expensive, and ran for barely eight minutes... 
with one of my two monitors powered off.  It didn't last long and I 
didn't replace it.)

Before the ordered data mode (back on Mandrake), I did have problems on 
occasion, and had to use it.  The infamous complaint about --rebuild-tree 
on reiserfs is that if you happen to put a loopback reiserfs in a file on 
reiserfs, rebuild-tree sees the superblock of the loopback and doesn't 
realize it's a loopback.  However, that's simple enough to avoid, just 
don't put loopback reiserfs images on reiser filesystems.  ISO-9660, fat, 
etc, those loopbacks are I believe fine (I know I've not had problems 
with them).  Just don't put reiserfs on reiserfs, but I've never had 
reason to do that anyway.  Other than that, what rebuild-tree does is go 
thru the filesystem data and make anything that looks like a file back 
into one, assigning a random name and putting it in lost&found, of 
course.  Some of those may have already been deleted, and just not 
cleared due to the corrupted journal due to unordered mode thus not 
caught at journal playback; some may be more direct metadata tree damage 
(a directory may have been lost but all its former files will show up, 
for instance) due to a crash in unordered mode at the wrong moment, etc.

I suppose it's possible that the check and journal playback at mount 
might not catch something if there's a hardware failure, but since 
data=ordered became the default, I've never seen such, and as I said, I 
had a LOT of crashes during part of that period, so it seems pretty 
robust to me.

The other thing I used to see before ordered mode was reiserfs zeroing 
out files, on occasion, on after-crash mount.  Again, I've not seen such 
behavior since ordered mode, which has been several years now.

Anyway, what I'd actually recommend is disabling fsck on reiserfs at 
boot, but then running a --check manually, every six months or so (this 
of course assumes you boot more often than every six months, of course) 
Truth be told, I haven't done the checks here at all, and haven't seen 
issues, but I /do/ do full backups periodically, and expect I'd notice 
problems if files were going unreadable.  Also, my important stuff is on 
RAID-6, which /does/ get thrown into recovery mode every once in awhile 
after a crash.  Folks without that two-way checksum verification on their 
important stuff are more likely to have statistical noise disk errors 
creep in occasionally, and if they aren't running checks say a couple 
times a year, those could eventually develop into pretty big data 
issues.  But it'd take time, and, I haven't seen anything like that on my 
RAID-0 either.  Not that I'd be as likely to catch it there, because I do 
not back it up since it's just stuff like the portage and kernel trees 
that are easily redownloaded, and ccache, so I don't worry much about it, 
but as I said, I've not /seen/ any issues, not a single one, that the 
boot process didn't fix, since ordered mode.

One thing with reiserfs, if the filesystems were cleanly unmounted, 
mounting is nearly instant -- it does the quick-checks and there's no 
journal replay since that was synced at shutdown, and the mount is really 
fast.  But the boot-time fscks were slower.  Get rid of them and you WILL 
notice a speedup.  The 4-way RAID of course helps here, and baselayout2/
openrc actually works with parallel boot, but the hardware BIOS check is 
now the majority of my boot time by a VERY great margin (several times 
over), with grub and the kernel-to-operational taking about the same time 
each, time that's only a fraction of the BIOS check process time.  With 
the fscks, it took MUCH longer (kernel-to-operational was about the same 
as the BIOS check), since those were both slow and can't be well 
parallelized since nearly everything else depends on the fscks, and 
nearly all of what doesn't, the fscks depend on.

> and, if you have experiences with it, do you know what could happen
> without fsck on an unsafely unmounted luks partition?

Luks I know nothing of.  Someday when I get the appropriate round tuit...

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman