ReiserFS / 2.4.6 / Data Corruption

as I am not on the mailing list.

The other day a computer of mine lost power and the ext2 fs was severely damaged
. I decided to reinstall debian using reiserfs to prevent this. I had no problems with installation, (I've done this same install on other computers) but as I started to untar backup tarballs I had made, I started noticing problems with what I believe is the filesystem.

Tar/gzip will complain about crc errors in files:
for example in a certain 40 mb file I can decompress fine on other computers. If I try to uncompress the same file immediately, it will fail at a different point, seemingly at random. Sometimes it works fine. Random debian packages I apt-get have the same problem. Sometimes they won't unpack properly, sometimes they will.

I tried reinstall gzip several times, but I don't think the problems are limited to compressed files, just very obvious in critical situations like that.

I can get complex software to run: xfree86 4.1, mozilla, etc, fine, although som
e files apparently go missing in some programs.

Just now I got the following error message when deleting a tarball:

vs-4080: reiserfs_free_block: free_block (0301:672040)[dev:blocknr]: bit already
cleared

Next, I took the hard drive to my other, stable computer and ran reiserfsck --rebuild-tree on it, under the hopes that this would fix it. It did appear to fix it, but about 10 minutes later the symptoms came back.

Here is 'debugreiserfs /dev/hda1' output:

Super block of format 3.5 found on the 0x3 in block 16
Block count 4233112
Blocksize 4096
Free blocks 3900694
Busy blocks (skipped 16, bitmaps - 130, journal blocks - 8193
1 super blocks, 324078 data blocks
Root block 8529
Journal block (first) 18
Journal dev 0
Journal orig size 8192
Filesystem state ERROR
Tree height 4
Hash function used to sort names: "tea" Objectid map size 62, max 1004
Version 0

Here is my relevant hardware:

Motherboard: Asus A7V KT133 with 686A southbridge (NOT the 686B).
Harddrive: 30 gig ide maxtor/generic.

I installed 2.4.6 to try and fix the problem, it didn't seem to help, although I do not clearly remember the difference between 2.2.17-patched and 2.4.6 in terms of the symptoms.

I tried reinstalling once, but that did not help.

I'm at a loss as to how to proceed. Any ideas?

Thank you for your time,

Sam
---
[email protected]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected] More majordomo info at
http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

First, please CC all replies to [email protected], as I am not on the mailing list.

The other day a computer of mine lost power and the ext2 fs was severely damaged
. I decided to reinstall debian using reiserfs to prevent this. I had no problems with installation, (I've done this same install on other computers) but as I started to untar backup tarballs I had made, I started noticing problems with what I believe is the filesystem.

Tar/gzip will complain about crc errors in files: for example in a certain 40 mb file I can decompress fine on other computers. If I try to uncompress the same file immediately, it will fail at a different point, seemingly at random. Sometimes it works fine. Random debian packages I apt-get have the same problem. Sometimes they won't unpack properly, sometimes they will.

I tried reinstall gzip several times, but I don't think the problems are limited to compressed files, just very obvious in critical situations like that.

I can get complex software to run: xfree86 4.1, mozilla, etc, fine, although som e files apparently go missing in some programs.

Just now I got the following error message when deleting a tarball:

vs-4080: reiserfs_free_block: free_block (0301:672040)[dev:blocknr]: bit already
cleared

Next, I took the hard drive to my other, stable computer and ran reiserfsck --rebuild-tree on it, under the hopes that this would fix it. It did appear to fix it, but about 10 minutes later the symptoms came back.

Here is 'debugreiserfs /dev/hda1' output:

Super block of format 3.5 found on the 0x3 in block 16 Block count 4233112
Blocksize 4096
Free blocks 3900694
Busy blocks (skipped 16, bitmaps - 130, journal blocks - 8193 1 super blocks, 324078 data blocks
Root block 8529
Journal block (first) 18
Journal dev 0
Journal orig size 8192
Filesystem state ERROR
Tree height 4
Hash function used to sort names: "tea"
Objectid map size 62, max 1004
Version 0

Here is my relevant hardware:

Motherboard: Asus A7V KT133 with 686A southbridge (NOT the 686B).
Harddrive: 30 gig ide maxtor/generic.

I installed 2.4.6 to try and fix the problem, it didn't seem to help, although I do not clearly remember the difference between 2.2.17-patched and 2.4.6 in terms of the symptoms.

I tried reinstalling once, but that did not help.

I'm at a loss as to how to proceed. Any ideas?

Thank you for your time,

Sam
---
[email protected]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Tar/gzip will complain about crc errors in files: for example in a certain 40 mb file I can decompress fine on other computers. If I try to uncompress the same file immediately, it will fail at a different point, seemingly at random. Sometimes it works fine. Random debian packages I apt-get have the same problem. Sometimes they won't unpack properly, sometimes they will.

My advice:

Dont use reiserfs,JFS
it is ok to use ext2

Go journalling? use ext3 or XFS

I have used all of these fs and pick up this rule (up to now, not sure it remains right in the far future)

Hi

If you are able to get a problem easily - would you mind to start with simple hardware checking (just to ):
does your CPU's cooler rotate?
is CPU temperature ok?
check memory with some tool

Thanks,
vs

Quoted 62 lines

Quoted 58 lines · Sam Thompson

First, please CC all replies to [email protected], as I am not on the mailing list.

The other day a computer of mine lost power and the ext2 fs was severely damaged
. I decided to reinstall debian using reiserfs to prevent this. I had no problems with installation, (I've done this same install on other computers) but as I started to untar backup tarballs I had made, I started noticing problems with what I believe is the filesystem.

Tar/gzip will complain about crc errors in files: for example in a certain 40 mb file I can decompress fine on other computers. If I try to uncompress the same file immediately, it will fail at a different point, seemingly at random. Sometimes it works fine. Random debian packages I apt-get have the same problem. Sometimes they won't unpack properly, sometimes they will.

I tried reinstall gzip several times, but I don't think the problems are limited to compressed files, just very obvious in critical situations like that.

I can get complex software to run: xfree86 4.1, mozilla, etc, fine, although som e files apparently go missing in some programs.

Just now I got the following error message when deleting a tarball:

vs-4080: reiserfs_free_block: free_block (0301:672040)[dev:blocknr]: bit already
cleared

Next, I took the hard drive to my other, stable computer and ran reiserfsck --rebuild-tree on it, under the hopes that this would fix it. It did appear to fix it, but about 10 minutes later the symptoms came back.

Here is 'debugreiserfs /dev/hda1' output:

Super block of format 3.5 found on the 0x3 in block 16 Block count 4233112
Blocksize 4096
Free blocks 3900694
Busy blocks (skipped 16, bitmaps - 130, journal blocks - 8193 1 super blocks, 324078 data blocks
Root block 8529
Journal block (first) 18
Journal dev 0
Journal orig size 8192
Filesystem state ERROR
Tree height 4
Hash function used to sort names: "tea"
Objectid map size 62, max 1004
Version 0

Here is my relevant hardware:

Motherboard: Asus A7V KT133 with 686A southbridge (NOT the 686B).
Harddrive: 30 gig ide maxtor/generic.

I installed 2.4.6 to try and fix the problem, it didn't seem to help, although I do not clearly remember the difference between 2.2.17-patched and 2.4.6 in terms of the symptoms.

I tried reinstalling once, but that did not help.

I'm at a loss as to how to proceed. Any ideas?

Thank you for your time,

Sam
---
[email protected]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

I should have checked this first, but you were right. Memtest86 revealed I had a bad memory module. When I replaced it, everything began running flawlessly. I've been running for several hours with no problems.

Thank you very much,
Sam

Quoted 76 lines · * Vladimir V. Saveliev ([email protected]) wrote:

Hi

If you are able to get a problem easily - would you mind to start with simple hardware checking (just to ):
does your CPU's cooler rotate?
is CPU temperature ok?
check memory with some tool

Thanks,
vs

Quoted 62 lines

Quoted 58 lines · Sam Thompson

First, please CC all replies to [email protected], as I am not on the mailing list.

The other day a computer of mine lost power and the ext2 fs was severely damaged
. I decided to reinstall debian using reiserfs to prevent this. I had no problems with installation, (I've done this same install on other computers) but as I started to untar backup tarballs I had made, I started noticing problems with what I believe is the filesystem.

Tar/gzip will complain about crc errors in files: for example in a certain 40 mb file I can decompress fine on other computers. If I try to uncompress the same file immediately, it will fail at a different point, seemingly at random. Sometimes it works fine. Random debian packages I apt-get have the same problem. Sometimes they won't unpack properly, sometimes they will.

I tried reinstall gzip several times, but I don't think the problems are limited to compressed files, just very obvious in critical situations like that.

I can get complex software to run: xfree86 4.1, mozilla, etc, fine, although som e files apparently go missing in some programs.

Just now I got the following error message when deleting a tarball:

vs-4080: reiserfs_free_block: free_block (0301:672040)[dev:blocknr]: bit already
cleared

Next, I took the hard drive to my other, stable computer and ran reiserfsck --rebuild-tree on it, under the hopes that this would fix it. It did appear to fix it, but about 10 minutes later the symptoms came back.

Here is 'debugreiserfs /dev/hda1' output:

Super block of format 3.5 found on the 0x3 in block 16 Block count 4233112
Blocksize 4096
Free blocks 3900694
Busy blocks (skipped 16, bitmaps - 130, journal blocks - 8193 1 super blocks, 324078 data blocks
Root block 8529
Journal block (first) 18
Journal dev 0
Journal orig size 8192
Filesystem state ERROR
Tree height 4
Hash function used to sort names: "tea"
Objectid map size 62, max 1004
Version 0

Here is my relevant hardware:

Motherboard: Asus A7V KT133 with 686A southbridge (NOT the 686B).
Harddrive: 30 gig ide maxtor/generic.

I installed 2.4.6 to try and fix the problem, it didn't seem to help, although I do not clearly remember the difference between 2.2.17-patched and 2.4.6 in terms of the symptoms.

I tried reinstalling once, but that did not help.

I'm at a loss as to how to proceed. Any ideas?

Thank you for your time,

Sam
---
[email protected]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Quoted 5 lines · wrote:

My advice:

Dont use reiserfs,JFS
it is ok to use ext2

Quoted 3 lines

Go journalling? use ext3 or XFS

I have used all of these fs and pick up this rule

(up

Quoted 1 line

to now, not sure it remains right in the far

future)

FUD. I've been using reiserfs on quite some systems

and never got any
problem. If reiserfs wouldn't be stable, SuSE wouldn't have supported
it as one of their stable filesystems for over a year.

Erik

Signature · 16 lines

J.A.K. (Erik) Mouw, Information and Communication
Theory Group, Department
of Electrical Engineering, Faculty of Information
Technology and Systems,
Delft University of Technology, PO BOX 5031,  2600
GA Delft, The Netherlands
Phone: +31-15-2783635  Fax: +31-15-2781843  Email:
[email protected]
WWW: http://www-ict.its.tudelft.nl/~erik/
-
To unsubscribe from this list: send the line
"unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at 
http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/ 

--- Erik Mouw <[email protected]> wrote: > On
Wed, Jul 18, 2001 at 03:18:59PM +1000, Steve Kieu

Quoted 6 lines

Quoted 5 lines · wrote:

My advice:

Dont use reiserfs,JFS
it is ok to use ext2

Quoted 8 lines

Quoted 3 lines

Go journalling? use ext3 or XFS

I have used all of these fs and pick up this rule

(up

Quoted 1 line

to now, not sure it remains right in the far

future)

FUD. I've been using reiserfs on quite some systems

Probably !. I said just from my computer, :-)

Reiserfs uses system resources more than others. Perfomance is ok (not as far more or less than JFS) but after using for a while, some mysterious things happen ; for example, the ini file of some program is changed wihtout any reason. For example I run mc and make it learn all keys, and pause when executing a command ; After reboot, sometimes all these setting are lost, some times not. It still happen with XFS though but never see in ext2, ext3 (now I am using)

JFS I was happy to use that when my computer is normal power off. One time, power outage then it completely trashed my root partition (can not recover by any means) Have to restore from backup file and sure, let it go for now.

I aggree Reiserfs should be stable but unfortunately in my computer it doesn's show any good sign of advantages than xfs or ext3. Dont mention about some minor bug like zero log file (fixed already I hope) but the data. Ahhh, I remember one time when I ran

pppd call myisp

pppd can not make the connection. I view the syslog file and noticed that chat send the wrong command to the modem. Strange, I thought as it is usually ok to make the connection. Check the /etc/ppp/chat/myisp file ; things seem to be normal. Ok I delete that file and edit it again exactly what I saw in the previous file. Run pppd call myisp; it is Ok. What do you think?

It has not yet happen to me now, for about 2 weeks (with ext3)

Okay may be that is FUD ; lets be like that way. I only say from my usage.

Cheers,

Quoted 18 lines

and never got any
problem. If reiserfs wouldn't be stable, SuSE wouldn't have supported
it as one of their stable filesystems for over a year.

Erik

--
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands
Phone: +31-15-2783635 Fax: +31-15-2781843 Email:
[email protected]

Quoted 8 lines

WWW: http://www-ict.its.tudelft.nl/~erik/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected] More majordomo info at
http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

=====
S.KIEU

_____________________________________________________________________________
http://messenger.yahoo.com.au - Yahoo! Messenger
- Voice chat, mail alerts, stock quotes and favourite news and lots more! -
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

--- Erik Mouw <[email protected]> wrote: > On

Quoted 1 line

FUD. I've been using reiserfs on quite some systems

Probably !. I said just from my computer, :-)

Reiserfs uses system resources more than others. Perfomance is ok (not as far more or less than JFS) but after using for a while, some mysterious things happen ; for example, the ini file of some program is changed wihtout any reason. For example I run mc and make it learn all keys, and pause when executing a command ; After reboot, sometimes all these setting are lost, some times not. It still happen with XFS though but never see in ext2, ext3 (now I am using)

Quoted 5 lines · Steve Kieu

My advice:

Dont use reiserfs,JFS
it is ok to use ext2

Quoted 4 lines

Go journalling? use ext3 or XFS

I have used all of these fs and pick up this rule (up to now, not sure it remains right in the far future)

FUD. I've been using reiserfs on quite some systems and never got any problem. If reiserfs wouldn't be stable, SuSE wouldn't have supported it as one of their stable filesystems for over a year.

Quoted 6 lines · Erik Mouw

Quoted 5 lines · Steve Kieu

My advice:

Dont use reiserfs,JFS
it is ok to use ext2

Quoted 8 lines

Quoted 4 lines

Go journalling? use ext3 or XFS

I have used all of these fs and pick up this rule (up to now, not sure it remains right in the far future)

FUD. I've been using reiserfs on quite some systems and never got any problem. If reiserfs wouldn't be stable, SuSE wouldn't have supported it as one of their stable filesystems for over a year.

Actually, I've been having some nasty corruption problems as well with reiserfs. I develop my own drivers, and do occasionally make a mistake, and when that hangs the kernel it will also screw up all files touched just before it in a edit-make-install-try cycle. Which can be rather annoying, because you can start all over again (this effect randomly distributes the last touched sectors to the last touched files. Very nice effect, but not something I expect from a journalled filesystem).

Regards,

Bas Vermeulen

--
"God, root, what is difference?"
-- Pitr, User Friendly

"God is more forgiving."
-- Dave Aronson

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Quoted 18 lines · [email protected] wrote:

Quoted 6 lines · Erik Mouw

Quoted 5 lines · Steve Kieu

My advice:

Dont use reiserfs,JFS
it is ok to use ext2

Quoted 8 lines

Quoted 4 lines

Go journalling? use ext3 or XFS

I have used all of these fs and pick up this rule (up to now, not sure it remains right in the far future)

FUD. I've been using reiserfs on quite some systems and never got any problem. If reiserfs wouldn't be stable, SuSE wouldn't have supported it as one of their stable filesystems for over a year.

Quoted 7 lines

Actually, I've been having some nasty corruption problems as well with reiserfs. I develop my own drivers, and do occasionally make a mistake, and when that hangs the kernel it will also screw up all files touched just before it in a edit-make-install-try cycle. Which can be rather annoying, because you can start all over again (this effect randomly distributes the last touched sectors to the last touched files. Very nice effect, but not something I expect from a journalled filesystem).

Do you think it is reasonable to ask that a filesystem be designed to work well with bad drivers?

Yup. I know ext2 can do it. I expect a filesystem to not foul up my data when something happens. Especially not shuffle around sectors in several files. I can understand that the changes I made are not on disc, I can even understand it if my files are gone, but not when it corrupts my data. That just plain sucks.

A friend of mine has had crashes as well (not reiser related btw), where files he was using at the time suddenly contained different pieces of different files. It's just plain annoying. The reason why *I* use(d) reiserfs was the fact that I thought that it would protect my data when something does crash. From my experience, it doesn't, and I'd rather wait a couple of minutes for ext2 to fsck than use reiserfs and be sure I can start all over again.

Regards,

Bas Vermeulen

Quoted 27 lines · Hans Reiser

Quoted 18 lines · [email protected] wrote:

Quoted 6 lines · Erik Mouw

Quoted 5 lines · Steve Kieu

My advice:

Dont use reiserfs,JFS
it is ok to use ext2

Quoted 8 lines

Quoted 4 lines

Go journalling? use ext3 or XFS

I have used all of these fs and pick up this rule (up to now, not sure it remains right in the far future)

FUD. I've been using reiserfs on quite some systems and never got any problem. If reiserfs wouldn't be stable, SuSE wouldn't have supported it as one of their stable filesystems for over a year.

Quoted 7 lines

Actually, I've been having some nasty corruption problems as well with reiserfs. I develop my own drivers, and do occasionally make a mistake, and when that hangs the kernel it will also screw up all files touched just before it in a edit-make-install-try cycle. Which can be rather annoying, because you can start all over again (this effect randomly distributes the last touched sectors to the last touched files. Very nice effect, but not something I expect from a journalled filesystem).

Quoted 2 lines

Do you think it is reasonable to ask that a filesystem be designed to work well with bad drivers?

Yup. I know ext2 can do it. I expect a filesystem to not foul up my data when something happens. Especially not shuffle around sectors in several files. I can understand that the changes I made are not on disc, I can even understand it if my files are gone, but not when it corrupts my data. That just plain sucks.

A friend of mine has had crashes as well (not reiser related btw), where files he was using at the time suddenly contained different pieces of different files. It's just plain annoying. The reason why *I* use(d) reiserfs was the fact that I thought that it would protect my data when something does crash. From my experience, it doesn't, and I'd rather wait a couple of minutes for ext2 to fsck than use reiserfs and be sure I can start all over again.

Regards,

Bas Vermeulen

--
"God, root, what is difference?"
-- Pitr, User Friendly

"God is more forgiving."
-- Dave Aronson

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

I've almost quit using reiser, because everytime I have a power outage, the last 2 or three files that I've editted, even ones that I haven't touched in a while, will usually be hopelessly corrupted. The '<file>~' that Emacs
makes is usually fine though. It seems to be that any open file is
in danger. I don't know if this is normal, or not, but I switched to XFS on several machines. I have nothing against reiser. I assumed that these problems were due to immaturity....

One more thing - All my computers with Reiser as '/' on them had a
disturbingly long boot time. From the time when the Redhat startup scripts
began, it was.... hideously slow. I thought nothing of it, blaming bash,

etc, Until I switched to ext2 on all those. Now the boot time is... SUPER fast. [3 Computers, 1 K6-2, a Pentium III, and a Pentium II, all 128+meg, and IDE] I currently have 3 computers running reiserfs left, all are using MySQL databases.
Once, I lost power in on my SQL box, [it was blessedly during a
period of no use.] I had to rebuild all the indexes. Not only THAT, but what happens to that box if I lose power whilst in the middle of operations? I am working on the migration plan to move that to XFS because of these concerns. [However, I am doing a better job of testing with XFS first.]

I think that Reiser is cool, and has neat ideology, but I am un-nerved by
this behaviour.

js

Quoted 18 lines

Yup. I know ext2 can do it. I expect a filesystem to not foul up my data when something happens. Especially not shuffle around sectors in several files. I can understand that the changes I made are not on disc, I can even understand it if my files are gone, but not when it corrupts my data. That just plain sucks.

A friend of mine has had crashes as well (not reiser related btw), where files he was using at the time suddenly contained different pieces of different files. It's just plain annoying. The reason why *I* use(d) reiserfs was the fact that I thought that it would protect my data when something does crash. From my experience, it doesn't, and I'd rather wait a couple of minutes for ext2 to fsck than use reiserfs and be sure I can start all over again.

Regards,

Bas Vermeulen

we all have different usage patterns and different needs. I find it extremely convenient to not be using ext2 when my dell laptop with its poor linux power management crashes frequently, or the kernel crashes. I have never had any problem with data corruption. Many users I know have also had good experiences with leaving behind ext2 and going to reiserfs on their laptops. For your needs and patterns though, it sounds like you need ext3.

I've almost quit using reiser, because everytime I have a power outage, the last 2 or three files that I've editted, even ones that I haven't touched in a while, will usually be hopelessly corrupted.

The '<file>~' that Emacs makes is usually fine though.

Once, I lost power in on my SQL box, [it was blessedly during a
period of no use.] I had to rebuild all the indexes. Not only THAT, but what happens to that box if I lose power whilst in the middle of operations? I am working on the migration plan to move that to XFS because of these concerns. [However, I am doing a better job of testing with XFS first.]

I think that Reiser is cool, and has neat ideology, but I am
un-nerved by this behaviour.

Quoted 3 lines · Joshua Schmidlkofer

I've almost quit using reiser, because everytime I have a power outage, the last 2 or three files that I've editted, even ones that I haven't touched in a while, will usually be hopelessly corrupted.

My early flush patch will fix this, or at least it will if I get together with the ReiserFS guys and figure out how to integrate their flushing mechanism with the standard bdflush. Or they could incorporate the ideas from my early flush in their own flush daemon, though generalizing the standard flush would have more value in the long run.

Quoted 2 lines

The '<file>~' that Emacs makes is usually fine though.

Because it's "created" by a rename.

[...]

Quoted 6 lines

Once, I lost power in on my SQL box, [it was blessedly during a
period of no use.] I had to rebuild all the indexes. Not only THAT, but what happens to that box if I lose power whilst in the middle of operations? I am working on the migration plan to move that to XFS because of these concerns. [However, I am doing a better job of testing with XFS first.]

Help is on its way. You can try full-data journalling with the journal on NVRAM or on a separate disk. You can also wait for me to get a

I think it's not hard to fix.

--
Daniel

FWIW, Debian although it doesn't support reiserfs "out of the box" at present, works flawlessly for a large number of people I know. I also hear Mandrake 7.2 and 8.0 work pretty nice if you want a pointy-clicky experience :)

Since so many people seem to run RedHat, perhaps it's worth someone determining exactly what is busted with their init scripts or whatever that makes reiserfs barf more often that with other distributions.

Quoted 6 lines · Daniel Phillips

Quoted 4 lines · Joshua Schmidlkofer

I've almost quit using reiser, because everytime I have a power outage, the last 2 or three files that I've editted, even ones that I haven't touched in a while, will usually be hopelessly corrupted.

Quoted 6 lines

My early flush patch will fix this, or at least it will if I get together with the ReiserFS guys and figure out how to integrate their flushing mechanism with the standard bdflush. Or they could incorporate the ideas from my early flush in their own flush daemon, though generalizing the standard flush would have more value in the long run.

Can you describe early flush?

I've almost quit using reiser, because everytime I have a power outage, the last 2 or three files that I've editted, even ones that I haven't touched in a while, will usually be hopelessly corrupted. The '<file>~' that Emacs makes is usually fine though.

It seems to be that any open file is
in danger. I don't know if this is normal, or not, but I switched to XFS on several machines. I have nothing against reiser. I assumed that these problems were due to immaturity....

Quoted 7 lines · Hans Reiser

Quoted 6 lines · Daniel Phillips

Quoted 4 lines · Joshua Schmidlkofer

I've almost quit using reiser, because everytime I have a power outage, the last 2 or three files that I've editted, even ones that I haven't touched in a while, will usually be hopelessly corrupted.

Quoted 8 lines

Quoted 6 lines

My early flush patch will fix this, or at least it will if I get together with the ReiserFS guys and figure out how to integrate their flushing mechanism with the standard bdflush. Or they could incorporate the ideas from my early flush in their own flush daemon, though generalizing the standard flush would have more value in the long run.

Can you describe early flush?

The idea is to do what amounts to a sync within a tenth of a second of disk bandwidth usage falling below a certain threshhold.

The original posts/patches are here:

[RFC] Early flush (was: spindown)
[RFC] Early flush: new, improved (updated)

and there are long threads attached to each of them. The clearest explanation is probably Jonathan Corbet's writeup on lwn:

   http://lwn.net/2001/0628/kernel.php3

(Thanks, Jonathan, I often get the feeling I understand what I actually did only *after* reading your writeups:-)

The second of the two patches needs more work - I think I goofed on some needed "volatile" handling, see the current flam^H^H^H^H thread about that.

--
Daniel

Quoted 5 lines · Joshua Schmidlkofer

I've almost quit using reiser, because everytime I have a power outage, the last 2 or three files that I've editted, even ones that I haven't touched in a while, will usually be hopelessly corrupted. The '<file>~' that Emacs makes is usually fine though.

It's a matter of timing. There is a lengthy window where the metadata is written, but its data is not. If you crash in this window, the files contain old data.

You can narrow the window of exposure by fiddling with the parameters in /proc/sys/vm/bdflush - force a full flush every five seconds, say.

Quoted 4 lines

It seems to be that any open file is
in danger. I don't know if this is normal, or not, but I switched to XFS on several machines. I have nothing against reiser. I assumed that these problems were due to immaturity....

I'm under the impression that XFS also leaves data in the hands of the kernel's normal writeback mechanisms and will thus be exposed to the same problem. I may be wrong about this.

Here's a ten-minute hack which gives reiserfs a simple `ordered data' mode. It simply pushes all the dirty buffers and pages out to disk before running a commit. Performance is still OK.

I hit reset partway through a massive file tree copy and every file which had been copied came up peachy - which is very different from the behaviour without the patch. Interestingly, there were zero truncated files as well. hmmm...

include/linux/fs.h Sat Jul 28 02:37:43 2001 renamed from include/linux/fs.h Sat Jul 21 12:37:14 2001 +1 -0

@@ -1061,6 +1061,7 @@ extern int fs_may_remount_ro(struct supe
 extern int try_to_free_buffers(struct page *, unsigned int);
 extern void refile_buffer(struct buffer_head * buf);
 extern void end_buffer_io_sync(struct buffer_head *bh, int uptodate);
+extern int flush_all_but_supers(kdev_t dev);
 
 /* reiserfs_writepage needs this */
 extern void set_buffer_async_io(struct buffer_head *bh) ;

include/linux/reiserfs_fs_sb.h Sat Jul 28 02:37:43 2001 renamed from include/linux/reiserfs_fs_sb.h Sat Jul 21 12:37:14 2001 +2 -0

@@ -289,6 +289,8 @@ struct reiserfs_sb_info
                                /* To be obsoleted soon by per buffer seals.. -Hans */
     atomic_t s_generation_counter; // increased by one every time the
     // tree gets re-balanced
+
+    int no_sync;
 
     /* session statistics */
     int s_kmallocs;

fs/reiserfs/journal.c Sat Jul 28 02:37:43 2001 renamed from fs/reiserfs/journal.c Sat Jul 21 12:37:14 2001 +3 -0

@@ -2719,6 +2719,9 @@ static int do_journal_end(struct reiserf
   reiserfs_discard_all_prealloc(th); /* it should not involve new blocks into
                                      * the transaction */
 #endif
+
+  if (!p_s_sb->u.reiserfs_sb.no_sync)
+       flush_all_but_supers(p_s_sb->s_dev);
 
   rs = SB_DISK_SUPER_BLOCK(p_s_sb) ;
   /* setup description block */

fs/reiserfs/super.c Sat Jul 28 02:37:43 2001 renamed from fs/reiserfs/super.c Wed Jul 4 18:21:31 2001 +2 -0

@@ -116,7 +116,9 @@ void reiserfs_put_super (struct super_bl
   /* note, journal_release checks for readonly mount, and can decide not
   ** to do a journal_end
   */
+  s->u.reiserfs_sb.no_sync = 1;
   journal_release(&th, s) ;
+  s->u.reiserfs_sb.no_sync = 0;
 
   for (i = 0; i < SB_BMAP_NR (s); i ++)
     brelse (SB_AP_BITMAP (s)[i]);

fs/buffer.c Sat Jul 28 02:37:43 2001 renamed from fs/buffer.c Sat Jul 21 12:37:14 2001 +12 -0

@@ -333,6 +333,18 @@ int fsync_dev(kdev_t dev)
        return sync_buffers(dev, 1);
 }
 
+int flush_all_but_supers(kdev_t dev)
+{
+       sync_buffers(dev, 0);
+
+       lock_kernel();
+       sync_inodes(dev);
+       DQUOT_SYNC(dev);
+       unlock_kernel();
+
+       return sync_buffers(dev, 1);
+}
+
 /*
  * There's no real reason to pretend we should
  * ever do anything differently

kernel/ksyms.c Sat Jul 28 02:37:43 2001 renamed from kernel/ksyms.c Sat Jul 21 12:37:14 2001 +1 -0

@@ -161,6 +161,7 @@ EXPORT_SYMBOL(d_lookup);
 EXPORT_SYMBOL(__d_path);
 EXPORT_SYMBOL(mark_buffer_dirty);
 EXPORT_SYMBOL(set_buffer_async_io); /* for reiserfs_writepage */
+EXPORT_SYMBOL(flush_all_but_supers);
 EXPORT_SYMBOL(__mark_buffer_dirty);
 EXPORT_SYMBOL(__mark_inode_dirty);
 EXPORT_SYMBOL(get_empty_filp);

You can narrow the window of exposure by fiddling with the parameters in /proc/sys/vm/bdflush - force a full flush every five seconds, say.

Quoted 2 lines

It seems to be that any open file is
in danger. I don't know if this is normal, or not, but I switched to XFS o

n

Quoted 2 lines

several machines. I have nothing against reiser. I assumed that these problems were due to immaturity....

I'm under the impression that XFS also leaves data in the hands of the kernel's normal writeback mechanisms and will thus be exposed to the same problem. I may be wrong about this.

Andrew, can you do this such that there is no disruption of our disk format, and make a mount option
out of it, and probably we should use this patch....

After you make a mount option out of it, grev will benchmark it for us using the usual suite of benchmarks.

This "feature" of not guaranteeing that a write that is in progress when the machine crashes will

not write garbage, has been present in most Unix filesystems for about 25 years of Unix history.

It

is not that we are deviant on this, it is that a tradeoff is made, and for most but not all users it

is a good one to make.

Quoted 4 lines · Hans Reiser

Andrew, can you do this such that there is no disruption of our disk format, and make a mount option
out of it, and probably we should use this patch....

I'll defer to Chris :)

There's no disruption to disk format - it just simulates the user typing `sync' at the right time. I think the concept is sound, and I'm sure Chris can find a more efficient way...

Quoted 4 lines

After you make a mount option out of it, grev will benchmark it for us using the usual suite of benchmarks.

Ordered-data is a funny thing. Under heavy loads it tends to make a significant throughput difference - on ext3 it almost halves throughput wrt writeback mode.

But this by no means indicates that writes are half as slow; what happens is that metadata-intensive workloads fill the journal up quickly, so the `sync' happens more frequently. Under normal workloads, or less metadata-intense workloads the difference is very small.

During testing of that little patch I noted that the disk went crunch every thirty seconds or so, which is good. Presumably the reiserfs journal is larger, or more space-efficient.

-

Quoted 5 lines · Hans Reiser

This "feature" of not guaranteeing that a write that is in progress when the machine crashes will

not write garbage, has been present in most Unix filesystems for about 25 years of Unix history.

A write in progress causing garabage when the power is lost is a driver, and drive thing.

stock unix behavior is that it delays writes for up to 30 seconds,
which in case of a crash could mean you have old data on disk. Not
wrong data. This is helped because in stock unix filesystems blocks are rarely reallocated or moved. In reiserfs with the btree at least some kinds of data are moved all over the disk.

I want to suspect a btree problem on the block jumping around (it's a good canidate). But unless you have messed up metadata journalling btree writes are journaled. The reason I am suspecting the btree is that most source code files are small so probably don't have complete filesystem blocks of their own.

If you can give me an explanation of what would cause the described behavior of small files swapping their contents I would believe I would feel more secure than just a reflex ``we don't garantee all of the data written before power failure''.

Quoted 17 lines · Eric W. Biederman

Quoted 5 lines · Hans Reiser

This "feature" of not guaranteeing that a write that is in progress when the machine crashes will

not write garbage, has been present in most Unix filesystems for about 25 years of Unix history.

A write in progress causing garabage when the power is lost is a driver, and drive thing.

stock unix behavior is that it delays writes for up to 30 seconds,
which in case of a crash could mean you have old data on disk. Not
wrong data. This is helped because in stock unix filesystems blocks are rarely reallocated or moved. In reiserfs with the btree at least some kinds of data are moved all over the disk.

Quoted 5 lines

I want to suspect a btree problem on the block jumping around (it's a good canidate). But unless you have messed up metadata journalling btree writes are journaled. The reason I am suspecting the btree is that most source code files are small so probably don't have complete filesystem blocks of their own.

Possibly. We're talking 130 kByte in total. The above is the reason why I don't like using reiserfs on my development system. My files get completely garbled, with the data randomly distributed over the files last touched. (Object files, dependency files, source files and header files) I don't mind loosing data I've just written, but I *hate* it when it garbles all my files.

Quoted 4 lines

If you can give me an explanation of what would cause the described behavior of small files swapping their contents I would believe I would feel more secure than just a reflex ``we don't garantee all of the data written before power failure''.

Bas Vermeulen

--
"God, root, what is difference?"
-- Pitr, User Friendly

"God is more forgiving."
-- Dave Aronson

Possibly. We're talking 130 kByte in total. The above is the reason why I don't like using reiserfs on my development system. My files get completely garbled, with the data randomly distributed over the files

not write garbage, has been present in most Unix filesystems for about 25 years of Unix history. It is not that we are deviant on this, it is that a tradeoff is made, and for most but not all users it is a good one to make.

I don't mind loosing data I've just written, but I *hate* it when it garbles all my files.

On Fri, Jul 27, 2001 at 06:55:09PM +0400, Hans Reiser wrote:

Don't use RedHat with ReiserFS, they screw things up so many ways.....

For instance, they compile it with the wrong options set, their boot scripts are wrong, they just shovel software onto the CD.

Use SuSE, and trust me, ReiserFS will boot faster than ext2.

Actually, I am curious as to exactly how they manage to make ReiserFS boot longer than ext2. Do they run fsck or what?

FWIW, Debian although it doesn't support reiserfs "out of the box" at present, works flawlessly for a large number of people I know. I also hear Mandrake 7.2 and 8.0 work pretty nice if you want a pointy-clicky experience :)

Since so many people seem to run RedHat, perhaps it's worth someone determining exactly what is busted with their init scripts or whatever that makes reiserfs barf more often that with other distributions.

--cw
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

You should not see old data being corrupted. If you are seeing it with a recent ReiserFS version,
we'd like your help in reproducing it.

Quoted 4 lines · [email protected] wrote:

Possibly. We're talking 130 kByte in total. The above is the reason why I don't like using reiserfs on my development system. My files get completely garbled, with the data randomly distributed over the files

How about using notail -option?

Quoted 4 lines

You should not see old data being corrupted. If you are seeing it with a recent ReiserFS version,
we'd like your help in reproducing it.

It is not old data perse. I edited those files. They have been opened, and written back. But it will shuffle every bit of data in those files, and I'll find sourcecode in the object file, *.d files, etc. The source file itself is mostly garbled as well.

I can see if I can come up with a module as simple as possible to reproduce this. (This is still a while(1); in kernel essentially, with a couple of seconds between the hang and the compile/install cycle)

If you're interested, let me know, and I'll see if I can make a test-case for you.

Bas Vermeulen

--
"God, root, what is difference?"
-- Pitr, User Friendly

"God is more forgiving."
-- Dave Aronson

Quoted 8 lines · Joshua Schmidlkofer

I've almost quit using reiser, because everytime I have a power outage, the last 2 or three files that I've editted, even ones that I haven't touched in a while, will usually be hopelessly corrupted. The '<file>~'
that Emacs makes is usually fine though. It seems to be that any open
file is in danger. I don't know if this is normal, or not, but I switched to XFS on several machines. I have nothing against reiser. I assumed that these problems were due to immaturity....

Quoted 4 lines

One more thing - All my computers with Reiser as '/' on them had a
disturbingly long boot time. From the time when the Redhat startup
scripts began, it was.... hideously slow. I thought nothing of it,
blaming bash,

Don't use RedHat with ReiserFS, they screw things up so many ways.....

For instance, they compile it with the wrong options set, their boot scripts are wrong, they just shovel software onto the CD.

Use SuSE, and trust me, ReiserFS will boot faster than ext2.

Actually, I am curious as to exactly how they manage to make ReiserFS boot longer than ext2. Do they run fsck or what?

Hans

Quoted 25 lines · Hans Reiser

Quoted 16 lines · [email protected] wrote:

Quoted 6 lines · Erik Mouw

Quoted 5 lines · Steve Kieu

My advice:

Dont use reiserfs,JFS
it is ok to use ext2

Quoted 8 lines

Quoted 4 lines

Go journalling? use ext3 or XFS

I have used all of these fs and pick up this rule (up to now, not sure it remains right in the far future)

FUD. I've been using reiserfs on quite some systems and never got any problem. If reiserfs wouldn't be stable, SuSE wouldn't have supported it as one of their stable filesystems for over a year.

Quoted 7 lines

Actually, I've been having some nasty corruption problems as well with reiserfs. I develop my own drivers, and do occasionally make a mistake, and when that hangs the kernel it will also screw up all files touched just before it in a edit-make-install-try cycle. Which can be rather annoying, because you can start all over again (this effect randomly distributes the last touched sectors to the last touched files. Very nice effect, but not something I expect from a journalled filesystem).

Quoted 2 lines

Do you think it is reasonable to ask that a filesystem be designed to work well with bad drivers?

Yup. I know ext2 can do it. I expect a filesystem to not foul up my data when something happens. Especially not shuffle around sectors in several files. I can understand that the changes I made are not on disc, I can even understand it if my files are gone, but not when it corrupts my data. That just plain sucks.

A friend of mine has had crashes as well (not reiser related btw), where files he was using at the time suddenly contained different pieces of different files. It's just plain annoying. The reason why *I* use(d) reiserfs was the fact that I thought that it would protect my data when something does crash. From my experience, it doesn't, and I'd rather wait a couple of minutes for ext2 to fsck than use reiserfs and be sure I can start all over again.

Regards,

Bas Vermeulen

What chipset have you got? I am running a PIII 550 w/ Intel BX chipset and ReiserFS (Kernel 2.4.7) and haven't run into any problems. Have you tried just sticking with the generic IDE driver and wait until the chipset specific driver becomes more stable?

Quoted 24 lines · Hans Reiser

Quoted 8 lines · Joshua Schmidlkofer

I've almost quit using reiser, because everytime I have a power outage, the last 2 or three files that I've editted, even ones that I haven't touched in a while, will usually be hopelessly corrupted. The '<file>~'
that Emacs makes is usually fine though. It seems to be that any open
file is in danger. I don't know if this is normal, or not, but I switched to XFS on several machines. I have nothing against reiser. I assumed that these problems were due to immaturity....

Quoted 4 lines

One more thing - All my computers with Reiser as '/' on them had a
disturbingly long boot time. From the time when the Redhat startup
scripts began, it was.... hideously slow. I thought nothing of it,
blaming bash,

Don't use RedHat with ReiserFS, they screw things up so many ways.....

For instance, they compile it with the wrong options set, their boot scripts are wrong, they just shovel software onto the CD.

Use SuSE, and trust me, ReiserFS will boot faster than ext2.

Actually, I am curious as to exactly how they manage to make ReiserFS boot longer than ext2. Do they run fsck or what?

Quoted 1 line

Hans

Regards to the ReiserFS. Something more spookie, OpenLinux (no boos and hisses please ;) ), they have ReiserFS as a module, yet, when I have the root partition as reiser I have no problems, voo doo magic perhaps? because when I compiled 2.4.7 w/ ReiserFS as a module, the boot forks up.

Also, to speed it up, I have heard a urban myth (I am not too sure whether it is true), you add the tag notail. A little more disk space is used, however, apparently, it is meant to speed up access.

Regards to the ReiserFS. Something more spookie, OpenLinux (no boos and hisses please ;) ), they have ReiserFS as a module, yet, when I have the root partition as reiser I have no problems, voo doo magic perhaps? because when I compiled 2.4.7 w/ ReiserFS as a module, the boot forks up.

Regarding the last comment, I think Redhat and Caldera have debugging enable (God knows why?), well, Caldera definately dones, after having a look at their default kernel configuration, hence, when I recompiled my kernel to 2.4.7, threw the reiserFS into the guts of the kernel with debugging turned off, there was a speed increase.

Regards to the ReiserFS. Something more spookie, OpenLinux (no boos and hisses please ;) ), they have ReiserFS as a module, yet, when I have the root partition as reiser I have no problems, voo doo magic perhaps? because when I compiled 2.4.7 w/ ReiserFS as a module, the boot forks up.

Regarding the last comment, I think Redhat and Caldera have debugging enable (God knows why?), well, Caldera definately dones, after having a look at their default kernel configuration, hence, when I recompiled my kernel to 2.4.7, threw the reiserFS into the guts of the kernel with debugging turned off, there was a speed increase.

Hi Matthew,

Quoted 4 lines · In article <[email protected]> you wrote:

Regards to the ReiserFS. Something more spookie, OpenLinux (no boos and hisses please ;) ), they have ReiserFS as a module, yet, when I have the root partition as reiser I have no problems, voo doo magic perhaps? because when I compiled 2.4.7 w/ ReiserFS as a module, the boot forks up.

Well, as reiserfs is a module it needs to be on the initrd. The install of the kernel kernel RPM automatically creates a new initrd which includes the modules in /etc/modules/rootfs. If you don't create a new initrd your modular reiserfs setup will of course fail.

Quoted 5 lines

Regarding the last comment, I think Redhat and Caldera have debugging enable (God knows why?), well, Caldera definately dones, after having a look at their default kernel configuration, hence, when I recompiled my kernel to 2.4.7, threw the reiserFS into the guts of the kernel with debugging turned off, there was a speed increase.

Reiserfs as implemented in the 2.4.2-based kernel of OpenLinux 3.1 is everything but stable and has a lot of issues (e.g. NFS-exporting doesn't work). That is the reason why it is a) marked experimental and is completly unsupported (and that is written _big_ _fat_ in manuals and similar stuff) and b) has debugging enabled to have the additional sanity checks that are under this option and give addtional hints if reiserfs fails again.

Reiserfs as implemented in the 2.4.2-based kernel of OpenLinux 3.1 is everything but stable and has a lot of issues (e.g. NFS-exporting doesn't work). That is the reason why it is a) marked experimental and is completly unsupported (and that is written _big_ _fat_ in manuals and similar stuff) and b) has debugging enabled to have the additional sanity checks that are under this option and give addtional hints if reiserfs fails again.

Christoph

--
Of course it doesn't work. We've performed a software upgrade.

Quoted 8 lines · Christoph Hellwig

Reiserfs as implemented in the 2.4.2-based kernel of OpenLinux 3.1 is everything but stable and has a lot of issues (e.g. NFS-exporting doesn't work). That is the reason why it is a) marked experimental and is completly unsupported (and that is written _big_ _fat_ in manuals and similar stuff) and b) has debugging enabled to have the additional sanity checks that are under this option and give addtional hints if reiserfs fails again.

The debugging won't prevent a single crash, it will only print a diagnostic that might help to understand why it crashed.

It makes zero sense for a distro to
have it on, and I think we make that pretty clear in the help button. It would be nice if distros read the help buttons before selecting options when configuring their kernels.:-/

I make no claims that users should use ReiserFS as it is in a 2.4.2 kernel....

Quoted 10 lines · Hans Reiser

Quoted 8 lines · Christoph Hellwig

Reiserfs as implemented in the 2.4.2-based kernel of OpenLinux 3.1 is everything but stable and has a lot of issues (e.g. NFS-exporting doesn't work). That is the reason why it is a) marked experimental and is completly unsupported (and that is written _big_ _fat_ in manuals and similar stuff) and b) has debugging enabled to have the additional sanity checks that are under this option and give addtional hints if reiserfs fails again.

Quoted 2 lines

The debugging won't prevent a single crash, it will only print a diagnostic that might help to understand why it crashed.

I don't know when you took a look at you code the last time, but when I did some time before the COL 3.1 release, there were lots of places in the reiserfs code where functions assumed that they have valid arguments when compiled without debugging and did the check explicitly when compiled with. Given the state the reiserfs code is in I really prefer to see this option turned on.

But there is not one where they recover from invalid arguments without a panic (unless I failed to notice something),

so it gets you nothing except a message
that we the developers will find more informative when trying to find what made it crash.

Quoted 2 lines · Hans Reiser

But there is not one where they recover from invalid arguments without a panic (unless I failed to notice something),

Right.

Quoted 3 lines

so it gets you nothing except a message
that we the developers will find more informative when trying to find what made it crash.

Nope. It does a reiserfs_panic instead of letting the wrong arguments slipping into lower layers and possibly on disk and thus corrupting data.

And in my opinion correct data is much more worth than one crash more or less (especially with a journaling filesystem).

Christoph

--
Whip me. Beat me. Make me maintain AIX.

Quoted 2 lines · Hans Reiser

But there is not one where they recover from invalid arguments without a panic (unless I failed to notice something),

Right.

Quoted 3 lines

so it gets you nothing except a message
that we the developers will find more informative when trying to find what made it crash.

Nope. It does a reiserfs_panic instead of letting the wrong arguments slipping into lower layers and possibly on disk and thus corrupting data.

And in my opinion correct data is much more worth than one crash more or less (especially with a journaling filesystem).

Christoph

--
Whip me. Beat me. Make me maintain AIX.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Quoted 2 lines · Hans Reiser

But there is not one where they recover from invalid arguments without a panic (unless I failed to notice something),

Right.

Quoted 3 lines

so it gets you nothing except a message
that we the developers will find more informative when trying to find what made it crash.

Nope. It does a reiserfs_panic instead of letting the wrong arguments slipping into lower layers and possibly on disk and thus corrupting data.

And in my opinion correct data is much more worth than one crash more or less (especially with a journaling filesystem).

Christoph

--
Whip me. Beat me. Make me maintain AIX.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

There is nothing like a distro maintainer

overriding the design decisions made
by the lead architect of a package, not believing that said architect knows what the fuck he is doing.

We will make this unusable by you from this point onwards.

Quoted 1 line · Hans Reiser

There is nothing like a distro maintainer

[NOTE: I do not maintain the Caldera kernel RPM, but I was
involved in the decision to turn reiserfs debugging on]

Quoted 3 lines

overriding the design decisions made
by the lead architect of a package, not believing that said architect knows what the fuck he is doing.

Reiserfs lately had a lot of stability issues, reports of data corruption and as you said before you don't considere the reiserfs version in 2.4.2-ac stable yourself.

The averange user will not blame you if he loses data through a problem in reiserfs but the distribtuion, even if this filesystem is clearly marked unsupported.

Quoted 3 lines

We will make this unusable by you from this point onwards.

I do not see the debug kernel removed from the official kernel tree before reiserfs has proven known stable.

Of course there is still the option of CONFIG_REISERFS_FS=n if you intentionally want to make your filesystem less acceptable..

Christoph

--
Of course it doesn't work. We've performed a software upgrade.

Quoted 1 line · Hans Reiser

There is nothing like a distro maintainer

[NOTE: I do not maintain the Caldera kernel RPM, but I was
involved in the decision to turn reiserfs debugging on]

Quoted 3 lines

overriding the design decisions made
by the lead architect of a package, not believing that said architect knows what the fuck he is doing.

Reiserfs lately had a lot of stability issues, reports of data corruption and as you said before you don't considere the reiserfs version in 2.4.2-ac stable yourself.

The cost is not a crash, the cost is performance sucks.

Are you going to leave it on for future versions of ReiserFS, or just for Linux 2.4.2?

Quoted 6 lines · Christoph Hellwig

Nope. It does a reiserfs_panic instead of letting the wrong arguments slipping into lower layers and possibly on disk and thus corrupting data.

And in my opinion correct data is much more worth than one crash more or less (especially with a journaling filesystem).

There is nothing like a distro maintainer overriding the design decisions made by the lead architect of a package, not believing that said architect knows what the fuck he is doing.

On Tue, Jul 31, 2001 at 01:48:03AM +0400, Hans Reiser wrote:

I also don't consider any 2.4 prior to 2.4.4 to be stable, and I don't consider 2.4.4 to be especially stable but it is usable.

Shipping 2.4.2 is something you and RedHat did for understandable marketing reasons. SuSE waited for 2.4.4.

This is a myth.

As has been explained --- RedHat does _NOT_ ship a stock kernel. Redhat 2.4.2 is not the same as stock/linux 2.4.2 so you are comparing apples with oranges.

Quoted 5 lines · Christoph Hellwig

Nope. It does a reiserfs_panic instead of letting the wrong arguments slipping into lower layers and possibly on disk and thus corrupting data.

And in my opinion correct data is much more worth than one crash more or less (especially with a journaling filesystem).

The cost is not a crash, the cost is performance sucks.

Quoted 11 lines · Hans Reiser

Quoted 6 lines · Christoph Hellwig

Nope. It does a reiserfs_panic instead of letting the wrong arguments slipping into lower layers and possibly on disk and thus corrupting data.

And in my opinion correct data is much more worth than one crash more or less (especially with a journaling filesystem).

There is nothing like a distro maintainer overriding the design decisions made by the lead architect of a package, not believing that said architect knows what the fuck he is doing.

Are you actually saying you don't care about user's data, or is it just my imagination ?

(I hope it's my imagination ...)

cheers,

Rik
--
Executive summary of a recent Microsoft press release:
"we are concerned about the GNU General Public License (GPL)"

                http://www.surriel.com/

http://www.conectiva.com/ http://distro.conectiva.com/

Quoted 9 lines · Hans Reiser

Quoted 5 lines · Christoph Hellwig

Nope. It does a reiserfs_panic instead of letting the wrong arguments slipping into lower layers and possibly on disk and thus corrupting data.

And in my opinion correct data is much more worth than one crash more or less (especially with a journaling filesystem).

The cost is not a crash, the cost is performance sucks.

If you can chose between sucky performance or a chance at silent data corruption ... which would you chose ?

Rik
--
Executive summary of a recent Microsoft press release:
"we are concerned about the GNU General Public License (GPL)"

                http://www.surriel.com/

http://www.conectiva.com/ http://distro.conectiva.com/

Are you actually saying you don't care about user's data, or is it just my imagination ?

(I hope it's my imagination ...)

cheers,

Rik
--
Executive summary of a recent Microsoft press release:
"we are concerned about the GNU General Public License (GPL)"

		http://www.surriel.com/

http://www.conectiva.com/ http://distro.conectiva.com/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

How does compiling in debug infrastructure protect the user's data? By making the file system so slow that he won't use it? :-)

Quoted 6 lines · Rik van Riel

Quoted 1 line · Hans Reiser

The cost is not a crash, the cost is performance sucks.

If you can chose between sucky performance or a chance at silent data corruption ... which would you chose ?

If you could halve linux memory manager performance and check as many things as reiserfs checks, would you do it.

.. You made the right choice.

Now, if you add a #define, you can check as many things as ReiserFS checks, and still go just as fast....

Quoted 2 lines

If you could halve linux memory manager performance and check as many things as reiserfs checks, would you do it.

I haven't removed a single debugging check from the 2.4 VM. Performance is MUCH more reliant on things like evicting the right page from RAM or reading in the right page at the right time.

CPU usage is only secondary.

Quoted 1 line

.. You made the right choice.

Thanks ;) [yeah, yeah ... flame me about out-of-context]

Quoted 2 lines

Now, if you add a #define, you can check as many things as ReiserFS checks, and still go just as fast....

I'm sure these checks make reiserfs a tad more CPU hungry, but isn't the real win in reiserfs supposed to come from superior disk layout, readahead across files, etc... ?

Or is that all just a myth ?

regards,

Rik
--
Executive summary of a recent Microsoft press release:
"we are concerned about the GNU General Public License (GPL)"

                http://www.surriel.com/

http://www.conectiva.com/ http://distro.conectiva.com/

For example I've just turned of the debugging on my ext3-using boxens.

I also don't consider any 2.4 prior to 2.4.4 to be stable, and I don't consider 2.4.4 to be especially stable but it is usable.

Shipping 2.4.2 is something you and RedHat did for understandable marketing reasons. SuSE waited for 2.4.4.

Quoted 5 lines · Hans Reiser

I also don't consider any 2.4 prior to 2.4.4 to be stable, and I don't consider 2.4.4 to be especially stable but it is usable.

Shipping 2.4.2 is something you and RedHat did for understandable marketing reasons. SuSE waited for 2.4.4.

Well, SuSE shipped 2.4.2 on their 7.1 release and I didn't see you jumping up and down in anger for "shipping an unstable release":

ftp://ftp.suse.com/pub/suse/i386/7.1/full-names/i386/k_i386_24-2.4.2-12.i386.rpm

Ah, but then again, you got money from them... He who pays the piper, calls the tune. And you're a fine piper.

Sorry, but I can't take you seriously. Especially as you're _so_ _obviously_ vendor biased, that it stinks.

Regards
Henning

--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [email protected]

Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [email protected]
D-91054 Buckenhof Fax.: 09131 / 50654-20
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

All the distros I know of except debian like to put kernel patches into their distros first. You would think they would want them in the kernel first so that they could know they are stable, but that would give them no "advantage". Sigh. I suppose there are much worse things they could do.

On Tue, Jul 31, 2001 at 02:36:39AM +0400, Hans Reiser wrote:

If you could halve linux memory manager performance and check as many things as reiserfs checks, would you do it. I think not, or else you would have. You made the right choice. Now, if you add a #define, you can check as many things as ReiserFS checks, and still go just as fast....

The memory manager is stress much more often that reiserfs, EVERYBODY has it.

The MM system does have various sanity checks, things might be slightly faster without them, but having the sanity checks is still very important.

If the memory manager does something bad, chances are your system will go boom --- upon reboot all is happy. If as fs goes bad, that corruption might still be there when you reboot, even if to another kernel! This is a major difference.

Anyhow, I use resierfs with debugging/checking on in lots of places. The speed difference is negligible, so I think this whole thread is pointless.

FWIW, if the mainline kernels remove the debugging option, I will hack it back in --- I for one am happy with the performance and am pleased there is additional sanity checking.

--cw

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

I am saying that you can put so many internal checks into a filesytem that it is unusable for any real usage. Guess what? ReiserFS does that! But we surround the checks with a #define. The only limit we have on the checks, is that after the relevant bug disappears we cut out the ones that make things so slow that it noticeably inconveniences our debugging. It has to slow things down quite a lot that we can't stand to wait for it while debugging, but there are some kinds of checks that you can do that are that slow.

ReiserFS checks more things than the rest of the kernel does. We can do this because we use the #define, and pay no price for it. You should do this also in your code....

Every major kernel component should have a #define which if on checks every imaginable thing the developer can think of to check regardless of how slow it makes the code go to check it. Then, when users (or at least as usefully, developers adding a new feature) have bugs in that component, they can turn it on.

Quoted 5 lines

Every major kernel component should have a #define which if on checks every imaginable thing the developer can think of to check regardless of how slow it makes the code go to check it. Then, when users (or at least as usefully, developers adding a new feature) have bugs in that component, they can turn it on.

Ugh! I think you need to have a little chat with Linus about this opinion of yours on how to use #ifdef / #endif in code... I'm not all that sure he'll agree with you.

From Dustin Byford:

From David Rees:

I'll try simply ensuring that users are warned that debugging is on first.

Of
course, with the way syslog is usually misconfigured on most distros we'll have to be careful to ensure that they ever see the messages.... Should I ask whether, with ReiserFS debugging on, and the default syslog.conf, the assertions being checked for on these particular distros ever reach the users? Better I not ask....?

If Chris wants to run ReiserFS with the checks on, fine, he is a user,

and he at
least knows he is doing it, but when a distro does it without warning users the FS is crippled it is really foul.

Well, if any of you users out there are interested in knowing practical details of how to overcome the shovelware,

I am _not_ a reiserfs user.

Last I ran benchmarks the performance cost was 30-40%, but this was some time ago. I think that the coders have been quietly culling some checks out of the FS, and so it does not cost as much anymore. I would prefer that the "excesive" checks had stayed in.

Sigh, I see I cannot persuade in this argument. It seems Linus is right, and debugging checks don't belong in debugged code even if they would make it easier for persons hacking on the code to debug their latest hacks.

On Tuesday, July 31, 2001 02:59:46 PM +0400 Hans Reiser <[email protected]> wrote:

[ CONFIG_REISERFS_CHECK ]

Quoted 9 lines

Last I ran benchmarks the performance cost was 30-40%, but this was some time ago. I think that the coders have been quietly culling some checks out of the FS, and so it does not cost as much anymore. I would prefer that the "excesive" checks had stayed in.

Sigh, I see I cannot persuade in this argument. It seems Linus is right, and debugging checks don't belong in debugged code even if they would make it easier for persons hacking on the code to debug their latest hacks.

In the end, the distributions are responsible for their own quality control, and they are free to turn on whatever debugging features they like. You can yell, scream, call them names, and in general piss them off however you like and they will still be absolutely correct in turning on whatever debugging check they feel is important.

The right way to deal with this is ask why they think it's important to turn on the checks. The goal behind code under CONFIG_REISERFS_CHECK is to add extra runtime consistency checks, but without CONFIG_REISERFS_CHECK on, the code should still make sure it isn't hosing the disk. In other words, the goal is like this:

if (some_error) {

#ifdef CONFIG_REISERFS_CHECK
    panic("some_error") ;

#else
gracefully_recover
#endif

There are places CONFIG_REISERFS_CHECK does extra scanning of the metadata and such, but all of these are supposed to be things that can be recovered from with the debugging off. Anything else is a bug.

-chris

Quoted 17 lines · Chris Mason

On Tuesday, July 31, 2001 02:59:46 PM +0400 Hans Reiser <[email protected]> wrote:

[ CONFIG_REISERFS_CHECK ]

Quoted 10 lines

Last I ran benchmarks the performance cost was 30-40%, but this was some time ago. I think that the coders have been quietly culling some checks out of the FS, and so it does not cost as much anymore. I would prefer that the "excesive" checks had stayed in.

Sigh, I see I cannot persuade in this argument. It seems Linus is right, and debugging checks don't belong in debugged code even if they would make it easier for persons hacking on the code to debug their latest hacks.

Quoted 5 lines

In the end, the distributions are responsible for their own quality control, and they are free to turn on whatever debugging features they like. You can yell, scream, call them names, and in general piss them off however you like and they will still be absolutely correct in turning on whatever debugging check they feel is important.

If they tell the user that the debugging is on and the FS is slowed. I think this is my solution, we will just make sure that the user knows with every mount and every boot that debug is on and things are going to be slow.

Quoted 14 lines

The right way to deal with this is ask why they think it's important to turn on the checks. The goal behind code under CONFIG_REISERFS_CHECK is to add extra runtime consistency checks, but without CONFIG_REISERFS_CHECK on, the code should still make sure it isn't hosing the disk. In other words, the goal is like this:

if (some_error) {

#ifdef CONFIG_REISERFS_CHECK
    panic("some_error") ;

#else
gracefully_recover
#endif

Quoted 5 lines

There are places CONFIG_REISERFS_CHECK does extra scanning of the metadata and such, but all of these are supposed to be things that can be recovered from with the debugging off. Anything else is a bug.

-chris

I am sorry Chris, but I cannot see the sense in what you say. CONFIG_REISERFS_CHECK is not a flag that indicates whether the user desires graceful recovery, it is a flag that indicates whether every imaginable check should be in the code, performance be damned, because there is a bug in the code somewhere, and we are desperately trying to get a clue about what its source is earlier in its life prior to the machine hanging.

(Bugs where there is a time lag between data structure corrupting and FS crashing are harder than others to debug, and checking the data structures excessively is one way to try to fing those bugs.) Making graceful recovery a selectable option is a separate topic.

There are lots of arguments that naturally arise in a development team about what checks are debug only and what ones belong outside. I lose many of these arguments to the betterment of ReiserFS. If persons not on the development team, and not involved in those discussions, and not end users, turn debug on and let users think it is normal slow motion reiserfs that they run, it screws our whole methodology.

It may help readers if they understand that Chris does not like the big heavy checks that one would not want to run all the time being inside CONFIG_REISERFS_CHECK.

Having levels of CONFIG_REISERFS_CHECK, in which one level is something to the effect of CHECK_EVERYTHING_YOU_CAN_WITHOUT_MY_NOTICING_THINGS_GOING_SLOWER, would be reasonable. We have what we have though.

On Tue, Jul 31, 2001 at 09:41:25AM -0400, Chris Mason wrote:

    if (some_error) {
    #ifdef CONFIG_REISERFS_CHECK
        panic("some_error") ;
    #else
        gracefully_recover
    #endif

What a terrible construct... if would be much more elegant as:

        if(some_error) {
                _namesys_internal_foo("some_error");
                recover_bar();
        }

where _namesys_internal_foo is compiled differently and may not return depending on CONFIG_REISERFS_CHECK and maybe also the error type.

Side note. I vaguely recall a distribution who's name has escaped me since. Thier selling point was "It's harder to install" and they claimed not to patch any source. "If it's good enough for the author, it's good enough for us". Might be worth checking out. If someone has a disro name for it, please...

If you can chose between sucky performance or a chance at silent data corruption ... which would you chose ?

I'd be very happy with full data journalling even with 50% performance penalty... There are applications that require extreme data integrity all times no matter what happens.

Just a side note to this discussion.

I'd be very happy with full data journalling even with 50% performance penalty... There are applications that require extreme data integrity all times no matter what happens.

Quoted 10 lines

Quoted 9 lines

Quoted 6 lines

Reiserfs as implemented in the 2.4.2-based kernel of OpenLinux 3.1 is everything but stable and has a lot of issues (e.g. NFS-exporting doesn't work). That is the reason why it is a) marked experimental and is completly unsupported (and that is written _big_ _fat_ in manuals and similar stuff) and b) has debugging enabled to have the additional sanity checks that are under this option and give addtional hints if reiserfs fails again.

The debugging won't prevent a single crash, it will only print a diagnostic that might help to understand why it crashed.

Quoted 6 lines

I don't know when you took a look at you code the last time, but when I did some time before the COL 3.1 release, there were lots of places in the reiserfs code where functions assumed that they have valid arguments when compiled without debugging and did the check explicitly when compiled with. Given the state the reiserfs code is in I really prefer to see this option turned on.

But there is not one where they recover from invalid arguments without a panic (unless I failed to notice something), so it gets you nothing except a message that we the developers will find more informative when trying to find what made it crash. We check invalid arguments at entry to reiserfs, and for those we

Quoted 3 lines

I'd be very happy with full data journalling even with 50% performance penalty... There are applications that require extreme data integrity all times no matter what happens.

How about an idea I proposed a while back, 'integrity loopback'?

A loopback device which writes a CRC with each block and checks the CRC when read back.