ReiserFS replaying the journal on every boot

alienDog · 08-01-2006, 08:10 AM

I have a system with 3 harddisks with one partition each. Two of them are using ReiserFS (root+one other) and one Ext3. The problem is that on every boot the journal of the non-root ReiserFS gets replayed. This happens after a clean shutdown also. Why? What do I do with it?

Zmyrgel · 08-01-2006, 08:37 AM

I think you have the checking enabled in /etc/fstab. Could you check which numbers it has in the end of it's line there?

win32sux · 08-01-2006, 11:25 AM

Quote:

Originally Posted by Zmyrgel

I think you have the checking enabled in /etc/fstab. Could you check which numbers it has in the end of it's line there?

which number would it have for journal-replay to be made every startup??

also, isn't it supposed to check the journal every startup, but only replay it if it finds transactions which were incomplete??

alienDog · 08-01-2006, 01:36 PM

Quote:

Originally Posted by win32sux

which number would it have for journal-replay to be made every startup??

also, isn't it supposed to check the journal every startup, but only replay it if it finds transactions which were incomplete??

I thin you are right, it has 1 1. I think one of them (I don't remember which one) has to do with backup and one with checking the disk. It still shouldn't replay the journal after a clean shutdown. Root filesystem (which is also Reiser) also has 1 1, but the journal for that doesn't get replayed. Instead I just get a message saying that the filesystem is clean.

raska · 08-01-2006, 01:41 PM

set them numbers to

Code:

1   2

the root partition ( / ) should have

Code:

1   1

win32sux · 08-01-2006, 01:58 PM

Quote:

Originally Posted by raska

set them numbers to

Code:

1   2

the root partition ( / ) should have

Code:

1   1

not really... at least not according to the FAQ: http://namesys.com/faq.html#fstab

win32sux · 08-01-2006, 02:00 PM

aliendog, is it possible for you to copy the data over to a known-good partition, and then reformat the one that's giving you trouble, and then copying the data back to it??

i'd also set the fields to zero as recommended by namesys (that's how they are currently on my slackware box actually)...

burninGpi · 08-01-2006, 02:15 PM

The first number at the end of the line is the dump field, which tells whether or not the filesystem should be backed up. In most cases, this should be 0; however, on / it should be 1.

The last number is the fsck field. It tells if the filesystem should be checked on boot. All removeable media should have this set to 0, and / should have 1. Any other partitons you want checked should have 2.

Quote:

What should I put into the fifth (aka dump, fs_freq ) and the sixth (aka pass, fs_passno ) fields of /etc/fstab for ReiserFS filesystems?

Code:

0 0

Accually, you SHOULD check reiserfs (and other) filesystems, just in case the fs gets corrupted (it can happen).

win32sux · 08-01-2006, 04:26 PM

Quote:

Originally Posted by burninGpi

Accually, you SHOULD check reiserfs [...] filesystems, just in case the fs gets corrupted (it can happen).

so could you explain why the reiserfs designers don't feel the same way??

could it have something to do with this??

Quote:

Why are ReiserFS filesystems not fscked on reboot after a crash?

Because ReiserFS provides journalling of meta-data. After a crash, the consistency of a filesystem is restored by replaying the transaction log.

sounds to me like the pass field serves no real purpose as far as reiserfs is concerned, and probably just needs to be filled with something for historical reasons... what say you??

raska · 08-01-2006, 04:41 PM

Quote:

Originally Posted by win32sux

not really... at least not according to the FAQ...[/url]

well, that is how I have them and I don't see checking themselves every boot (which happens about once in a month)

Focus in the OP's problem, not at flaming others.

BTW, alienDog, did it work?

win32sux · 08-01-2006, 04:48 PM

Quote:

Originally Posted by raska

Focus in the OP's problem, not at flaming others.

it makes sense to point-out that the filesystem's website recommends a setting different than what you have recommended - it's not personal - nobody is flaming anybody here, relax...

alienDog · 08-01-2006, 05:30 PM

Quote:

Originally Posted by win32sux

aliendog, is it possible for you to copy the data over to a known-good partition, and then reformat the one that's giving you trouble, and then copying the data back to it??

It's possible, it's just a backup drive. However it doesn't seem to make much sense to re-format it, the drive is only a few days old so it should be ok. I'll try 1 2 tomorrow.

win32sux · 08-01-2006, 05:35 PM

Quote:

Originally Posted by alienDog

It's possible, it's just a backup drive. However it doesn't seem to make much sense to re-format it, the drive is only a few days old so it should be ok.

yeah, i hear ya... hmmm, and of course, the issue might continue even after doing this... which would be even weirder... when did it start doing this?? had you made any changes, like to the BIOS, jumpers, slackware, etc??

burninGpi · 08-01-2006, 06:16 PM

Quote:

Originally Posted by win32sux

so could you explain why the reiserfs designers don't feel the same way??

My SUSE box got setup that way by default, and that was the first time I used reiserfs. But when the FS got corrupt, It was because I forgot the root password, and Knoppix didn't save properly.

But Yes, I see how it works now.

http://namesys.com/bad-block-handling.html

alienDog · 08-02-2006, 07:50 AM

Quote:

Originally Posted by win32sux

yeah, i hear ya... hmmm, and of course, the issue might continue even after doing this... which would be even weirder... when did it start doing this?? had you made any changes, like to the BIOS, jumpers, slackware, etc??

It's been doing this since I installed the new drive. That is... well... always

The only change I have made is installing the new drive. That also required changing the jumpers of the other drives on the system. The drives are as follows:

primary master, 20 GB reiserfs (os/root/boot)
secondary master, 160 GB ext3 shared to the network with nfs
primary slave, 160 GB reiserfs (backup of secondary master)
secondary slave, cd-rw