prevent file system corruption on hard lock-up
 

I've recently had my file system irrecoverably corrupted after a hard lock-up. This has happened to me before, a couple weeks ago, and both times I've had to reinstall. I don't know what is causing the lock-ups (possibly the binary nvidia driver..), but I would like my file system to be intact or at least recoverable next time it happens.

What is the "safest" way to mount things?

I'll be using ext3 with data=journal, but I've read that disk write caching combined with a kernel crash or power loss can still screw things up. Supposedly, mounting with barrier=1 helps some, but doesn't work with LVM? Would it be wise to turn off disk write caching completely? I understand there's a performance penalty, but if it helps keep the file system consistent in case of disaster..

Are there any other tricks or options to help alleviate file system corruption after an unclean reboot?

Running updated slackware 12.2 w/ 2.6.27.31 kernel..

Regarding disk caching, you should not turn it off. The performance and lifetime penalty on your hard drive is huge. Which file system were you using that it got corrupted without possibilities to recover?

Have you tied the "Raising Elephants Is So Utterly Boring" keys? This should shut your system down in a controlled manner when it's locked up.
Press Alt + SysRq (Print Screen) and in order hit the "REISUB" keys - hence the odd mnemonic phrase.

The first time, I was using reiserfs, and the second time it was ext3 (in ordered mode).. fsck wouldn't even run, unable to load shared library x. I booted a live CD, ran fsck, rebooted and then init complained about missing libraries as well, possibly due to fsck moving things to l+f?

When it froze up, I did try the SysRq save, but it didn't help. The screen was blank and wouldn't come on, I couldn't ssh in, so I don't really know if the machine was even responding to key presses at all.

Use EXT4FS, Luke! And stay in a super-duper-zero-day-updated slackware-current. ;)

12.2 have the age of my granny...

Well, I didn't want to run -current because it changes rapidly and things may break, but I also didn't want to run 13.0 because I use KDE and the version in 13.0 is.. well.. let's not go there. :D

Anyway, I've been reading a bit (actually, a lot) and I think I'm just going to upgrade the kernel on my 12.2 installation to 2.6.33+; from that version onwards, dm has full barrier support so I should be able to use LVM, mount my filesystems with data=journal,barrier=1 and still leave disk write caching on.

I known what your heart want... How about:

http://slackware.cs.utah.edu/pub/sla...for-slack13.0/

You should update also the filesystems and kernel utilities too... ;)

I've never had the filesystem become "irrecoverably corrupted" after a hard lock-up. It has always been fixed by an fsck, at least with JFS, and for as long as I've been using it.

What, exactly, would I need to update besides the kernel? The filesystems already know about barriers, so does mount.. As far as I can tell, the only piece missing is the ability for device-mapper to pass on the barriers to underlying devices (syslog agrees), and that was added in 2.6.33.. Or am I forgetting something?

I just tried it and it seems to be working. All I did was compile and install a 2.6.33.2 kernel, enable flush barriers in fstab, and reboot. Well, and I switched back to reiserfs, but this should work equally well with ext3. My log now shows:

whereas before the upgrade it showed:

I'll mark this resolved, even though it's kind of hard to test without yanking the power cord. :D