Beso <[email protected]> posted [email protected], 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
