# Hard resets kill reiser4?

## Rainmaker

Hi guys,

I have a pretty odd problem: every time I do a "hard" reset, my (reiser4) filesystem gets b0rked.

After a fsck everything seems to be fne, sometimes I have to run it twice to get all errors corrected, but no biggy.

Only problem is, I suffer some "data loss" when this happens. I put it in quotes, because it's not actually data loss, almost all files get renamed to lost_name_xxxxxx in my lost+found directory.

For example, last time this happened, I ended up with a screwed up home-dir (my setting, my settings!   :Laughing:  )

I'm really doubting the consistency of reiser4 now. Every time I do a hard reset, I've gotta cross my fingers everything works out OK. I'm missing the icons in my KDE menu now, for example. Re-emerging kdeartwork fixed that, but I might not always be so lucky  :Razz: .

Can anyone tell me what to do to improve my filesystem consistency?

----------

## Arainach

Yeah, use ext3.  Reiser4 is like XFS: If the power goes out, you're in trouble.

----------

## codergeek42

 *Rainmaker wrote:*   

> Can anyone tell me what to do to improve my filesystem consistency?

 Use a more consistent filesystem?   :Wink: 

----------

## feld

don't do a hard reset? why are you doing these in the first place?

-Feld

----------

## Jake

 *Rainmaker wrote:*   

> ...Can anyone tell me what to do to improve my filesystem consistency?

 

Submit a bug report. Half-written data is sacrificed to maintain filesystem consistency, but you should never need to fsck. reiser4 was designed to tolerate hard resets and as far as Namesys knows, it does. Of course you'll want to be using the latest -mm or Namesys reiser4-for-2.6 patch before you submit a bug report, but seriously, this shouldn't be happening.

----------

## miseiler

 *Jake wrote:*   

>  *Rainmaker wrote:*   ...Can anyone tell me what to do to improve my filesystem consistency? 
> 
> Submit a bug report. Half-written data is sacrificed to maintain filesystem consistency, but you should never need to fsck. reiser4 was designed to tolerate hard resets and as far as Namesys knows, it does. Of course you'll want to be using the latest -mm or Namesys reiser4-for-2.6 patch before you submit a bug report, but seriously, this shouldn't be happening.

 

Could not agree more.

Atomicity is tailor-made to deal with these sorts of issues.  The idea is that if ANY sort of reset is made, either all the data was written, or none of it.

In my experience with reiser4, which has been admittedly only since it was released officially, this is exactly the behaviour it has exhibited.  Only once could I report something anything like what you're describing, and that was because I decided to use the Magic SysRq key to sync data first, and boy did reiser4 hate that.  Lost all the scripts in my /etc/init.d...

Use the latest patches.  Apply them yourself or use one of the numerous patchsets floating around these boards.

----------

## Rainmaker

 *miseiler wrote:*   

>  *Jake wrote:*    *Rainmaker wrote:*   ...Can anyone tell me what to do to improve my filesystem consistency? 
> 
> Submit a bug report. Half-written data is sacrificed to maintain filesystem consistency, but you should never need to fsck. reiser4 was designed to tolerate hard resets and as far as Namesys knows, it does. Of course you'll want to be using the latest -mm or Namesys reiser4-for-2.6 patch before you submit a bug report, but seriously, this shouldn't be happening. 
> 
> Could not agree more.
> ...

 

Thanks, I also thought atomicity (or whatever it's called  :Razz: ) was one of the key features of reiser4. Ofcourse I'm already using the latest patches, I'm now running the latest nitro / love kernel, which should have them on-board.

Hard resets are sometimes necessery. Everyone says linux can't crash, but trust me on this, it can  :Very Happy: 

Last reset was when using nitro "back to basic" with nvagp instead of agpart. That's enough to get a hard lockup (on my system at least).

I'll see if I can make some kind of script to reproduce this. Then I'll file a bug report. Guess I'll have to create a seperate partition for this  :Laughing: 

Now I'll just have to figure out the correct name of the 334 lost_nane files....  :Razz: .

----------

## Rainmaker

I'm a little bit further in diagnosising this:

I found the lines 

```
[hald] Keys are incosistent. Fsck?

reiser4/search.c: warning, search failed

```

In tty12 (the syslog console) just before my system stopped launching anything (KDE: "could not find application: xterm")

Strange thing is, I can't find the error message in my /var/log/messages

For some reason, I'm now having the same problem over and over again: KDE tells me it can't launch the application. If I try to login to a normal tty, the system hardlocks after entering the username.

Removing hald seemes to fix it, for how long I don't know.

I'd like to submit a bug report about this (high  priority, this is serious  :Razz: ), but I'd like to give the devs something more to go on then "hald breaks reiser4".

Where can I find those errors? I think they'll never get written to the log, because after the hard reset, everything in the buffers is  lost, including those errors...

----------

## John5788

isnt reiserfs the most stable or reliable FS:?

----------

## codergeek42

 *John5788 wrote:*   

> isnt reiserfs the most stable or reliable FS:?

 Far from it. The most stable and reliable filesystems is ext3.,(or ext2 if you're ok with not having journalling). The tools for those, as well as the kernelspace code, are the most tried and tested of any filesystem. The way it was designed, however, gives a lot of room for extensions and plugins such as access control lists, SELinux features, etc.. I tried ReiserFS with SuSE and with a recent failed attempt at a chrooted install. It corrupted both times. YMMV of course...

----------

## rmh3093

I have had my system lock up completly many time while playing with different kernels, nothing related to reiser4, never had any data loss. But, i did a hard power off a few times in a row right in the middle of the init process once and that trashed the root patition beyond repair

----------

## John5788

 *codergeek42 wrote:*   

>  *John5788 wrote:*   isnt reiserfs the most stable or reliable FS:? Far from it. The most stable and reliable filesystems is ext3.,(or ext2 if you're ok with not having journalling). The tools for those, as well as the kernelspace code, are the most tried and tested of any filesystem. The way it was designed, however, gives a lot of room for extensions and plugins such as access control lists, SELinux features, etc.. I tried ReiserFS with SuSE and with a recent failed attempt at a chrooted install. It corrupted both times. YMMV of course...

 

your lying   :Shocked: 

----------

## miseiler

 *John5788 wrote:*   

>  *codergeek42 wrote:*    *John5788 wrote:*   isnt reiserfs the most stable or reliable FS:? Far from it. The most stable and reliable filesystems is ext3.,(or ext2 if you're ok with not having journalling). The tools for those, as well as the kernelspace code, are the most tried and tested of any filesystem. The way it was designed, however, gives a lot of room for extensions and plugins such as access control lists, SELinux features, etc.. I tried ReiserFS with SuSE and with a recent failed attempt at a chrooted install. It corrupted both times. YMMV of course... 
> 
> your lying  

 

Heh.

I'm going to repeat something Hans Reiser said once about his filesystems (paraphrased, I'm lazy): "If you experience lockups or hard drive corruption with reiserfs, it's because you have bad hardware.  You may not think so, but reiserfs is much more stressful on components such as hard drives than any other filesystem."

This is true.  In reiser4, for instance, many people report increased hard drive temps (an average of 4 degrees C, iirc).

I myself have a hard drive in my computer I use for backup.  It's ext3 right now, because I've tried to install reiserfs (not even reiser4) on it countless times.  The drive gave me the click of death every time, yet it continued to allow me to reformat it with any other filesystem.  To this day, parted will crash if I ask it to look at the drive.  I've learned my lesson...reiser fileystems don't belong on old hardware.

----------

## Jake

Rainmaker,

I don't know Namesys's official position on nitro/love-sources, but I'm sure they'd rather have a crash report from vanilla or -mm.

Have you tried enabling debugging, especially assertions for reiser4? I can crash my AMD64 system with reiser4 and no debugging, but with it I just get annoying processes that won't die and other inconveniences requiring a reboot. The developers will probably want debugging enabled anyway, so it can't hurt to try.

If you still get lockups with debugging, you'll have to configure network logging or a serial console.

----------

## OOZafle

I'm running a pentium3 at 500mhz with an old 16gb fujitsu hard drive and i've  been running reiserfs on my root and boot partitions for over a year now and no problems. i'm not convinced it won't run on old hardware. maybe just certain hardware, thats just my experience though.

----------

## EricHsu

I once hard powered off my system, then I got my reiser4 system corrupted, and a problem like this one, but seems that no one knows how to fix it...   :Crying or Very sad: 

----------

## Archangel1

I've had a problem once, but no more than I'd expect from any other filesystem. Many other hard poweroffs have only resulted in data not being written - the atomic thing seems to apply to data I thought I'd written some time before, which is odd.

----------

## forbjok

 *Rainmaker wrote:*   

> Hard resets are sometimes necessery. Everyone says linux can't crash, but trust me on this, it can 

 

Who ever said Linux can't crash?

I can think of at least a few sure ways:

* Unplug USB storage device under 2.6.9 (possibly 2.6.8 too) kernel (coredump first, then eventually total freeze)

* Run X with mouse device pointing to /dev/psaux, with "legacy" psaux disabled in kernel (will only crash display, not actual system)

* Use ati-drivers (okay, sort of a joke, but hey, it's true  :Laughing: )

----------

