ReiserFS / 2.4.6 / Data Corruption

ReiserFS / 2.4.6 / Data Corruption

[Sam Thompson]

First, please CC all replies to samuelt@caltech.edu, 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
---
samuelt@caltech.edu

Re: ReiserFS / 2.4.6 / Data Corruption

[Steve Kieu]

Just from my experience of using fs:

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)

cheers


 --- Sam Thompson
<samuelt@cervantes.dabney.caltech.edu> wrote: > First,
please CC all replies to samuelt@caltech.edu,
> 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
> ---
> samuelt@caltech.edu
> -
> To unsubscribe from this list: send the line
> "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> 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!

Re: ReiserFS / 2.4.6 / Data Corruption

[Hans Reiser]

That you had problems on both filesystems makes me suspect the hard drive.  May I suggest you run
the badblocks program and see if it finds any?

My other developers may have other suggestions.

Hans

Sam Thompson wrote:
> 
> First, please CC all replies to samuelt@caltech.edu, 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
> ---
> samuelt@caltech.edu
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: ReiserFS / 2.4.6 / Data Corruption

[Andre Pang]

On Tue, Jul 17, 2001 at 09:14:01PM -0700, Sam Thompson wrote:

> 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.

you also possibly have a ram problem.  check out memtest86 at
freshmeat.net and try that.  anything can happen to a computer
if power dies unexpectedly.


-- 
#ozone/algorithm <ozone@algorithm.com.au>          - trust.in.love.to.save

Re: ReiserFS / 2.4.6 / Data Corruption

[Erik Mouw]

On Wed, Jul 18, 2001 at 03:18:59PM +1000, Steve Kieu wrote:
> 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)

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

-- 
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: J.A.K.Mouw@its.tudelft.nl
WWW: http://www-ict.its.tudelft.nl/~erik/

Re: ReiserFS / 2.4.6 / Data Corruption

[Sam Thompson]

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

* Vladimir V. Saveliev (monstr@namesys.com) 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
> 
> 
> > 
> > Sam Thompson wrote:
> > 
> >> First, please CC all replies to samuelt@caltech.edu, 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
> >> ---
> >> samuelt@caltech.edu
> >> -
> >> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> >> the body of a message to majordomo@vger.kernel.org
> >> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >> Please read the FAQ at  http://www.tux.org/lkml/
> > 
> 
> 

Re: ReiserFS / 2.4.6 / Data Corruption

[Hans Reiser]

It is very understandable that users should be less confident in the stability of our code than we
are.  At this time, hardware bugs that look very much like software bugs greatly outnumber software
bugs.  We find that if a bug is easy for the user to hit by doing something not especially unusual,
and it doesn't seem like recent VFS changes have caused it, it is almost surely a hardware bug
masquerading as a software bug.

Hans

Sam Thompson wrote:
> 
> 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
> 
> * Vladimir V. Saveliev (monstr@namesys.com) 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
> >
> >
> > >
> > > Sam Thompson wrote:
> > >
> > >> First, please CC all replies to samuelt@caltech.edu, 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
> > >> ---
> > >> samuelt@caltech.edu
> > >> -
> > >> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> > >> the body of a message to majordomo@vger.kernel.org
> > >> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: ReiserFS / 2.4.6 / Data Corruption

[Steve Kieu]

 --- Erik Mouw <J.A.K.Mouw@ITS.TUDelft.NL> wrote: > On
Wed, Jul 18, 2001 at 03:18:59PM +1000, Steve Kieu
> wrote:
> > 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)
> 
> 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,


> 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:
> J.A.K.Mouw@its.tudelft.nl
> 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 majordomo@vger.kernel.org
> 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!

Re: ReiserFS / 2.4.6 / Data Corruption

[Hans Reiser]

I think you have problems that are completely unrelated to ReiserFS.

Hans

Steve Kieu wrote:
> 
>  --- Erik Mouw <J.A.K.Mouw@ITS.TUDelft.NL> wrote: > On
> Wed, Jul 18, 2001 at 03:18:59PM +1000, Steve Kieu
> > wrote:
> > > 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)
> >
> > 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,
> 
> > 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:
> > J.A.K.Mouw@its.tudelft.nl
> > 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 majordomo@vger.kernel.org
> > 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: ReiserFS / 2.4.6 / Data Corruption

[Erik Mouw]

On Thu, Jul 19, 2001 at 12:02:59PM +1000, Steve Kieu wrote:
>  --- Erik Mouw <J.A.K.Mouw@ITS.TUDelft.NL> wrote: > On
> > 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)

That sounds more like hardware problems to me.


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: J.A.K.Mouw@its.tudelft.nl
WWW: http://www-ict.its.tudelft.nl/~erik/

Re: ReiserFS / 2.4.6 / Data Corruption

[bvermeul]

On Wed, 18 Jul 2001, Erik Mouw wrote:

> On Wed, Jul 18, 2001 at 03:18:59PM +1000, Steve Kieu wrote:
> > 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)
>
> 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

Re: ReiserFS / 2.4.6 / Data Corruption

[Hans Reiser]

bvermeul@devel.blackstar.nl wrote:
> 
> On Wed, 18 Jul 2001, Erik Mouw wrote:
> 
> > On Wed, Jul 18, 2001 at 03:18:59PM +1000, Steve Kieu wrote:
> > > 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)
> >
> > 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

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

Re: ReiserFS / 2.4.6 / Data Corruption

[bvermeul]

On Fri, 27 Jul 2001, Hans Reiser wrote:

> bvermeul@devel.blackstar.nl wrote:
> >
> > On Wed, 18 Jul 2001, Erik Mouw wrote:
> >
> > > On Wed, Jul 18, 2001 at 03:18:59PM +1000, Steve Kieu wrote:
> > > > 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)
> > >
> > > 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).
>
> 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

Re: ReiserFS / 2.4.6 / Data Corruption

[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.... 

   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


>
> 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

Re: ReiserFS / 2.4.6 / Data Corruption

[Hans Reiser]

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.

Hans

bvermeul@devel.blackstar.nl wrote:
> 
> On Fri, 27 Jul 2001, Hans Reiser wrote:
> 
> > bvermeul@devel.blackstar.nl wrote:
> > >
> > > On Wed, 18 Jul 2001, Erik Mouw wrote:
> > >
> > > > On Wed, Jul 18, 2001 at 03:18:59PM +1000, Steve Kieu wrote:
> > > > > 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)
> > > >
> > > > 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).
> >
> > 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: ReiserFS / 2.4.6 / Data Corruption

[Hans Reiser]

Joshua Schmidlkofer wrote:
> 
> 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,

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

> 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
> 
> >
> > 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

Re: ReiserFS / 2.4.6 / Data Corruption

[Chris Wedgwood]

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

Re: ReiserFS / 2.4.6 / Data Corruption

[bvermeul]

On Fri, 27 Jul 2001, Hans Reiser wrote:

> 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.

The point is, this can happen every time the kernel crashes, and reiserfs
wrote something to it's metadata logs (or so I gather from your and Alan's
explanation). And apart from my source files getting randomly distributed,
reiserfs works like a charm (I have a Dell as well, and it used to crash a
lot, which was the main reason for me to switch to reiserfs in the first
place), is fast, and stable. I like it a lot, but not on a machine where I
do my development on, nor a machine without a UPS. It just doesn't help
not knowing if/when a file gets corrupted/wrongly distributed/written
back/whatever.

It looks to me (with all my ignorance) that reiserfs shuffles it's blocks
a lot when writing back, and that bites when something interrupts it.
I can't back that up with code, put my finger to it or anything else, but
that's my take on my problems.

Bas Vermeulen

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

"God is more forgiving."
	-- Dave Aronson

Re: ReiserFS / 2.4.6 / Data Corruption

[Daniel Phillips]

On Friday 27 July 2001 16:18, Joshua Schmidlkofer wrote:
> 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.

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

Because it's "created" by a rename.

[...]
>     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 
usable version of Tux2 working.  It's progressed a little slowly 
because of frequent side trips ;-)  But hopefully I'll be able to do 
something about that soon.

Which flavor of SQL are you using?  Are the indices in separate files?  
(Sounds like they are.)

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

I think it's not hard to fix.

--
Daniel

Re: ReiserFS / 2.4.6 / Data Corruption

[Chris Wedgwood]

On Fri, Jul 27, 2001 at 08:18:12AM -0600, Joshua Schmidlkofer wrote:

        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.]

Sounds like a MySQL bug (assuming data is on disk when perhaps it's
not).  Using either Oracle or Sybase you seem to be able to yank the
power at pretty much any time even under load and things will recovery
gracefully upon restart.





  --cw

Re: ReiserFS / 2.4.6 / Data Corruption

[Hans Reiser]

Daniel Phillips wrote:
> 
> On Friday 27 July 2001 16:18, Joshua Schmidlkofer wrote:
> > 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.

Can you describe early flush?

> 
> > The '<file>~' that Emacs makes is usually fine though.
> 
> Because it's "created" by a rename.
> 
> [...]
> >     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

Well, if you have NVRAM, you might try using our new journal relocation patch to put the journal on
NVRAM.

> I think it's not hard to fix.
> 
> --
> Daniel

Re: ReiserFS / 2.4.6 / Data Corruption

[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.  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.

reiser4 will do it better though by making data logging available as an option with only a moderate
performance penalty.

Hans

Re: ReiserFS / 2.4.6 / Data Corruption

[Henning P. Schmiedehausen]

Chris Wedgwood <cw@f00f.org> writes:

>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.

There is nothing wrong with RedHat init scripts.

I run RH 6.2 on my self-rolled 2.2.x kernels and they boot ReiserFS
fine and neither faster nor slower than ext2. Nothing wrong with
RedHat here.

I consider a vendor that does not always ship "latest and greatest"
but tries to stress test its software superior to one that crams out
one new release every three months. And if they enable paranoia mode
in the experimental sections of the kernel: Fine! Goes well with my
philosophy of server running. Leads to 500+ days uptime.

I dropped out of ReiserFS again, however, because of unexplained
problems with various user space applications (PostgreSQL 6.5.3 and
7.x or Highwind oops bCandid oops Software.Com oops Highwind-again
Cyclone and Typhoon) that are heavy thread and mmap() users. 

I use ReiserFS for my ftp-data-caroussels and as spool and staging
disks. Not for system disks that contain binaries or performance
critical application disks. That works fine. 


	Regards
		Henning

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Re: ReiserFS / 2.4.6 / Data Corruption

[Daniel Phillips]

On Friday 27 July 2001 17:33, Hans Reiser wrote:
> Daniel Phillips wrote:
> > On Friday 27 July 2001 16:18, Joshua Schmidlkofer wrote:
> > > 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.
>
> 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

Re: ReiserFS / 2.4.6 / Data Corruption

[Andrew Morton]

Joshua Schmidlkofer wrote:
> 
> 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.

>   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...






--- linux-2.4.7/include/linux/fs.h	Sat Jul 21 12:37:14 2001
+++ lk-ext3/include/linux/fs.h	Sat Jul 28 02:37:43 2001
@@ -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) ;
--- linux-2.4.7/include/linux/reiserfs_fs_sb.h	Sat Jul 21 12:37:14 2001
+++ lk-ext3/include/linux/reiserfs_fs_sb.h	Sat Jul 28 02:37:43 2001
@@ -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;
--- linux-2.4.7/fs/reiserfs/journal.c	Sat Jul 21 12:37:14 2001
+++ lk-ext3/fs/reiserfs/journal.c	Sat Jul 28 02:37:43 2001
@@ -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 */
--- linux-2.4.7/fs/reiserfs/super.c	Wed Jul  4 18:21:31 2001
+++ lk-ext3/fs/reiserfs/super.c	Sat Jul 28 02:37:43 2001
@@ -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]);
--- linux-2.4.7/fs/buffer.c	Sat Jul 21 12:37:14 2001
+++ lk-ext3/fs/buffer.c	Sat Jul 28 02:37:43 2001
@@ -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
--- linux-2.4.7/kernel/ksyms.c	Sat Jul 21 12:37:14 2001
+++ lk-ext3/kernel/ksyms.c	Sat Jul 28 02:37:43 2001
@@ -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);

Early Flush

[Hans Reiser]

Daniel Phillips wrote:
> 
> On Friday 27 July 2001 17:33, Hans Reiser wrote:
> > Daniel Phillips wrote:
> > > On Friday 27 July 2001 16:18, Joshua Schmidlkofer wrote:
> > > > 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.
> >
> > 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
Daniel, what you have done is something that I have wanted and believed in for a long time.

Spell out what you need from us and we will support you.

Hans

Re: ReiserFS / 2.4.6 / Data Corruption

[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....

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

Comments Chris?  

Thanks,

Hans

Andrew Morton wrote:
> 
> Joshua Schmidlkofer wrote:
> >
> > 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.
> 
> >   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...
> 
> --- linux-2.4.7/include/linux/fs.h      Sat Jul 21 12:37:14 2001
> +++ lk-ext3/include/linux/fs.h  Sat Jul 28 02:37:43 2001
> @@ -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) ;
> --- linux-2.4.7/include/linux/reiserfs_fs_sb.h  Sat Jul 21 12:37:14 2001
> +++ lk-ext3/include/linux/reiserfs_fs_sb.h      Sat Jul 28 02:37:43 2001
> @@ -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;
> --- linux-2.4.7/fs/reiserfs/journal.c   Sat Jul 21 12:37:14 2001
> +++ lk-ext3/fs/reiserfs/journal.c       Sat Jul 28 02:37:43 2001
> @@ -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 */
> --- linux-2.4.7/fs/reiserfs/super.c     Wed Jul  4 18:21:31 2001
> +++ lk-ext3/fs/reiserfs/super.c Sat Jul 28 02:37:43 2001
> @@ -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]);
> --- linux-2.4.7/fs/buffer.c     Sat Jul 21 12:37:14 2001
> +++ lk-ext3/fs/buffer.c Sat Jul 28 02:37:43 2001
> @@ -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
> --- linux-2.4.7/kernel/ksyms.c  Sat Jul 21 12:37:14 2001
> +++ lk-ext3/kernel/ksyms.c      Sat Jul 28 02:37:43 2001
> @@ -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);

Re: ReiserFS / 2.4.6 / Data Corruption

[Steve Lord]

> 
> 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.
> 
> >   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
> > 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.
> 

Yes, XFS does leave writing the data to the normal writeback mechanisms, 
however, what happens with XFS is usually:

 o a file with no extents - the size made it out to disk but the data did not.
   since on writes to new space we do not allocate the space until we flush
   you tend not to see old data. The only way out of something like this is
   to prevent the inode size update from hitting disk until the file data
   is on disk. The performance consequences of doing that are probably 
   large.

   This situation is somewhat helped by the fact that if one page gets
   flushed by bdflush and it calls back into xfs to allocate space, we 
   will allocate space for, and flush all surrounding data in the file,
   so this may be causing earler flushing than might otherwise happen.

Since xfs usually operates with a much smaller in memory log than other
filesystems (64K default) and we have some synchronous transactions which
cause a flush of the in memory log, the amount that time can go backwards
by in a crash is a lot smaller.

Steve

Re: ReiserFS / 2.4.6 / Data Corruption

[Andrew Morton]

Hans Reiser wrote:
> 
> 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...


> 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.

-

Re: ReiserFS / 2.4.6 / Data Corruption

[Eric W. Biederman]

Hans Reiser <reiser@namesys.com> writes:

> 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.

> 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.

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''.

Eric

 

Re: ReiserFS / 2.4.6 / Data Corruption

[Hans Reiser]

Andrew Morton wrote:
> 
> Hans Reiser wrote:
> >
> > 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 :)

Yes, I'll let him think carefully through the details of how it affects ordering of the writes.


> 
> 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...

Oops, sorry, you changed the in-ram not the on-disk sb....

> 
> > 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.
> 
> -

Thanks Andrew

Re: ReiserFS / 2.4.6 / Data Corruption

[bvermeul]

On 27 Jul 2001, Eric W. Biederman wrote:

> Hans Reiser <reiser@namesys.com> writes:
>
> > 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.

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.

> 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

Re: ReiserFS / 2.4.6 / Data Corruption

[Hans Reiser]

bvermeul@devel.blackstar.nl wrote:
> 
> On 27 Jul 2001, Eric W. Biederman wrote:
> 
> > Hans Reiser <reiser@namesys.com> writes:
> >
> > > 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.
> 
> 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.
> 
> > 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
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.

Hans

Re: ReiserFS / 2.4.6 / Data Corruption

[Jussi Laako]

bvermeul@devel.blackstar.nl 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?

 - Jussi

-- 
PGP key fingerprint: 161D 6FED 6A92 39E2 EB5B  39DD A4DE 63EB C216 1E4B
Available at PGP keyservers

Re: ReiserFS / 2.4.6 / Data Corruption

[Lehmann]

On Fri, Jul 27, 2001 at 07:38:12PM +0400, Hans Reiser <reiser@namesys.com> wrote:
> 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.

it just happens muchg more with reiserfs than with other fs's. but I trust
chreis mason who said that this might be fixable. so it might not be a design
trade-off at all.

-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       pcg@goof.com      |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |

Re: ReiserFS / 2.4.6 / Data Corruption

[Daniel Phillips]

On Friday 27 July 2001 20:47, bvermeul@devel.blackstar.nl wrote:
> I don't mind loosing data I've just written, but I
> *hate* it when it garbles all my files.

Have you tried running with no tail merging?  (And no already-merged 
tails.)

--
Daniel

Re: ReiserFS / 2.4.6 / Data Corruption

[Luigi Genoni]

On Sat, 28 Jul 2001, Chris Wedgwood wrote:

> 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 :)
>
I could add that also slackware is just faster with / with reiserFS
than with ext2.
But i saw that some of RH init script are, how can I say, redundant....

Luigi

> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

Re: ReiserFS / 2.4.6 / Data Corruption

[bvermeul]

> 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

Re: ReiserFS / 2.4.6 / Data Corruption

[bvermeul]

On Fri, 27 Jul 2001, Jussi Laako wrote:

> bvermeul@devel.blackstar.nl 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?

Never tried it. I'll see if I can reproduce.

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

"God is more forgiving."
	-- Dave Aronson

Re: ReiserFS / 2.4.6 / Data Corruption

[Hans Reiser]

bvermeul@devel.blackstar.nl wrote:
> 
> > 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
I am very much interested in a test case.

hans

Re: ReiserFS / 2.4.6 / Data Corruption

[Matthew Gardiner]

On Saturday 28 July 2001 02:55, Hans Reiser wrote:
> Joshua Schmidlkofer wrote:
> > 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,
>
> 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

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.

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.

Matthew Gardiner
-- 
WARNING:

This email was written on an OS using the viral 'GPL' as its license.

Please check with Bill Gates before continuing to read this email/posting.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Re: ReiserFS / 2.4.6 / Data Corruption

[Matthew Gardiner]

On Saturday 28 July 2001 01:24, bvermeul@devel.blackstar.nl wrote:
> On Fri, 27 Jul 2001, Hans Reiser wrote:
> > bvermeul@devel.blackstar.nl wrote:
> > > On Wed, 18 Jul 2001, Erik Mouw wrote:
> > > > On Wed, Jul 18, 2001 at 03:18:59PM +1000, Steve Kieu wrote:
> > > > > 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)
> > > >
> > > > 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).
> >
> > 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?

Matthew Gardiner

-- 
WARNING:

This email was written on an OS using the viral 'GPL' as its license.

Please check with Bill Gates before continuing to read this email/posting.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Re: ReiserFS / 2.4.6 / Data Corruption

[bvermeul]

> 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?

Intel i815, and the thing is rock solid unless I fuck up with a driver.

Bas Vermeulen

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

"God is more forgiving."
	-- Dave Aronson

Re: ReiserFS / 2.4.6 / Data Corruption

[Hans Reiser]

Matthew Gardiner wrote:
> 
> On Saturday 28 July 2001 02:55, Hans Reiser wrote:
> > Joshua Schmidlkofer wrote:
> > > 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,
> >
> > 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
> 
> 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.

Perhaps there is a problem in which the reiserfs module does not get loaded
before you need to read the root partition?

If you isolate the problem to where you think it is a reiserfs bug, please let
me know.  It sounds like not.


> 
> 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.

This is entirely correct.  Moving tails around costs performance, ReiserFS
cannot give you something for nothing in this respect.

Hans

Re: ReiserFS / 2.4.6 / Data Corruption

[Marcus Meissner]

In article <01072901450000.02683@kiwiunixman.nodomain.nowhere> 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.

We have the reiserfs module in the initial ramdisk in such setups. 

You need to recreate the initrd in those cases.
(Run "/usr/libexec/modules/mkinitrd.sh 2.4.7" in the /boot directory, this
 will create /boot/initrd-2.4.7.gz.)

> 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 is experimental in the 2.4 series, thats why we ship with a big
disclaimer and with checking enabled.

(And before you argue again, we ship 2.4.2-ac26. Since then several major
 bugs have been found in reiserfs, including the knfsd lossage.)

Ciao, Marcus

Re: ReiserFS / 2.4.6 / Data Corruption

[Christoph Hellwig]

Hi Matthew,

In article <01072901450000.02683@kiwiunixman.nodomain.nowhere> 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.

> 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.

	Christoph

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

Re: ReiserFS / 2.4.6 / Data Corruption

[Matthew Gardiner]

On Sunday 29 July 2001 04:45, Christoph Hellwig wrote:
> Hi Matthew,
>
> In article <01072901450000.02683@kiwiunixman.nodomain.nowhere> 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.
>
> > 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.

I've upgraded to 2.4.7 without any problems. 

Regard to the above, that is, moduler ReiserFS, its not really an issue, as 
compiling into the kernel hasn't caused any problems.

Just a little suggestion. Is it possible to offer "kernel binary upgrades" 
every other major release, for example, it shipped with 2.4.2, hence, the 
next upgrade to be release, 2.4.4 then 2.4.6 then 2.4.8. I can compile 
everthing however, I know a couple of people too scared to get down into the 
nitty gritty of Linux and compile their own kernel.

Matthew Gardiner

-- 
WARNING:

This email was written on an OS using the viral 'GPL' as its license.

Please check with Bill Gates before continuing to read this email/posting.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Re: ReiserFS / 2.4.6 / Data Corruption

[Chris Wedgwood]

On Sun, Jul 29, 2001 at 10:19:32PM +1200, Matthew Gardiner wrote:

    Just a little suggestion. Is it possible to offer "kernel binary
    upgrades" every other major release, for example, it shipped with
    2.4.2, hence, the next upgrade to be release, 2.4.4 then 2.4.6
    then 2.4.8. I can compile everthing however, I know a couple of
    people too scared to get down into the nitty gritty of Linux and
    compile their own kernel.

Umm.. most (if not all) vendors provide kernel binary upgrades.  If
these are not frequent enough for your needs, you need to complain to
them.




  --cw

Re: ReiserFS / 2.4.6 / Data Corruption

[Hans Reiser]

Christoph Hellwig wrote:
> 
 
> 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....
> 
>         Christoph
> 
> --
> Of course it doesn't work. We've performed a software upgrade.

Re: ReiserFS / 2.4.6 / Data Corruption

[Christoph Hellwig]

On Mon, Jul 30, 2001 at 02:08:17PM +0400, Hans Reiser wrote:
> Christoph Hellwig wrote:
> > 
>  
> > 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.

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.

> 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.:-/

Well sometimes it's even better to take a look at the code..

	Christoph

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

No one said that (and even if I wouldn't believe him).

	Christoph

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

Re: ReiserFS / 2.4.6 / Data Corruption

[Hans Reiser]

Christoph Hellwig wrote:
> 
> On Mon, Jul 30, 2001 at 02:08:17PM +0400, Hans Reiser wrote:
> > Christoph Hellwig wrote:
> > >
> >
> > > 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.
> 
> 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
error gracefully.  (We also have some checks for garbage blocks having been
read, and we have made some efforts to error gracefully from those.) 

Hans

Re: ReiserFS / 2.4.6 / Data Corruption

[Christoph Hellwig]

On Tue, Jul 31, 2001 at 12:30:12AM +0400, Hans Reiser wrote:
> But there is not one where they recover from invalid arguments without a panic
> (unless I failed to notice something),

Right.

> 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.

Re: ReiserFS / 2.4.6 / Data Corruption

[Hans Reiser]

Christoph Hellwig wrote:
> 
> On Tue, Jul 31, 2001 at 12:30:12AM +0400, Hans Reiser wrote:
> > But there is not one where they recover from invalid arguments without a panic
> > (unless I failed to notice something),
> 
> Right.
> 
> > 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.


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.  Vitaly, I told you
what to do weeks ago in this regard, do it today.

Does it get worse than shovelware?  I suppose it does....

Hans

Re: ReiserFS / 2.4.6 / Data Corruption

[Hans Reiser]

The debugging tests in reiserfs were deliberately encouraged to be excessive and
performance unconcerned.  That is part of how we get programmers to write
excessively paranoid bug finding code, we tell them not to worry about the
effect on performance, it will only be used when looking for bugs.

People like you destroy my ability to get lots of tests put into the code by the
coders.

Hans

Christoph Hellwig wrote:
> 
> On Tue, Jul 31, 2001 at 12:30:12AM +0400, Hans Reiser wrote:
> > But there is not one where they recover from invalid arguments without a panic
> > (unless I failed to notice something),
> 
> Right.
> 
> > 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: ReiserFS / 2.4.6 / Data Corruption

[Hans Reiser]

Christoph Hellwig wrote:
> 
> On Tue, Jul 31, 2001 at 12:30:12AM +0400, Hans Reiser wrote:
> > But there is not one where they recover from invalid arguments without a panic
> > (unless I failed to notice something),
> 
> Right.
> 
> > 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).

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

> 
>         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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


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

Hans

Re: ReiserFS / 2.4.6 / Data Corruption

[Christoph Hellwig]

On Tue, Jul 31, 2001 at 01:05:11AM +0400, Hans Reiser wrote:
> 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]

> 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.

> 
> 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.

Re: ReiserFS / 2.4.6 / Data Corruption

[Hans Reiser]

Christoph Hellwig wrote:
> 
> On Tue, Jul 31, 2001 at 01:05:11AM +0400, Hans Reiser wrote:
> > 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]
> 
> > 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.
> 
> >
> > 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.

We'd rather be off, than have debug on.  Debug is not designed to be on, unless
you are debugging.  Most users don't know that you have turned debug on.  They
just think ReiserFS isn't as fast as their SuSE using friends say it is.  We
will make sure users know that their distro has turned debug on.

Hans

Re: ReiserFS / 2.4.6 / Data Corruption

[Hans Reiser]

Christoph Hellwig wrote:
> 
> On Tue, Jul 31, 2001 at 01:05:11AM +0400, Hans Reiser wrote:
> > 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]
> 
> > 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.

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.

Hans

Re: ReiserFS / 2.4.6 / Data Corruption

[Christoph Hellwig]

On Tue, Jul 31, 2001 at 01:21:09AM +0400, Hans Reiser wrote:
> 
> The cost is not a crash, the cost is performance sucks.
> 

I give a damn for the performance if my filesystem doesn't prove stable.
And I think you can't deny that all reiserfs versions for 2.4 had issues
in that area. _IF_ reiserfs proves stable in the next time I don't see
any reason why this checks should stay in.

For example I've just turned of the debugging on my ext3-using boxens.
Not only ext3 has proven stable, but I also know that if it fails there
is still e2fsck which has proven absolutly reliable in the last years.

Another example is the write support I currently add to my freevxfs driver
(and no, I'm neither working for RedHat nor is it the VxFS module that
played a central role in your 3/2000 conspiration theories):  until it has
proven stable for a long time I will not even add a option to turn off
all the consistency checks I've added.  I'll give a damn if ext2, reiserfs
or VERITAS will beat me until it is stable.

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

I'm not in a position to decide it.  But if I'm asked for my opion (again)
the answer will depend on wether reiserfs will be more stable than now
at that point.

	Christoph

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

Re: ReiserFS / 2.4.6 / Data Corruption

[Chris Wedgwood]

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.



  --cw

Re: ReiserFS / 2.4.6 / Data Corruption

[Christoph Hellwig]

On Tue, Jul 31, 2001 at 09:57:21AM +1200, Chris Wedgwood wrote:
> 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.

The same is true for Caldera, btw.

	Christoph

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

Re: ReiserFS / 2.4.6 / Data Corruption

[Rik van Riel]

On Tue, 31 Jul 2001, Hans Reiser wrote:
> Christoph Hellwig wrote:
> >
> > 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/

Re: ReiserFS / 2.4.6 / Data Corruption

[Rik van Riel]

On Tue, 31 Jul 2001, Hans Reiser wrote:
> Christoph Hellwig wrote:

> > 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/

Re: ReiserFS / 2.4.6 / Data Corruption

[Hans Reiser]

Rik van Riel wrote:
> 
> On Tue, 31 Jul 2001, Hans Reiser wrote:
> > Christoph Hellwig wrote:
> > >
> > > 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/

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.

Hans

Re: ReiserFS / 2.4.6 / Data Corruption

[Hans Reiser]

Rik van Riel wrote:
> 
> On Tue, 31 Jul 2001, Hans Reiser wrote:
> > Christoph Hellwig wrote:
> 
> > > 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/


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....

Hans

Re: ReiserFS / 2.4.6 / Data Corruption

[Kip Macy]

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

			-Kip

> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 

Re: ReiserFS / 2.4.6 / Data Corruption

[Christoph Hellwig]

On Mon, Jul 30, 2001 at 03:41:16PM -0700, Kip Macy wrote:
> How does compiling in debug infrastructure protect the user's data? By
> making the file system so slow that he won't use it? :-)

The <<reiserfs debugging code>> isn't debugging code in a strict sense.
It mostly it consists of sequences in the form of:

 (sometimes there is also code that the documentation states as deadlock-
 avoidance, why it is not enabled without _CHECK defined is left as
 exercise to the reader)

#ifdef CONFIG_REISERFS_CHECK
	if (condition_that_should_not_happen)
		reiserfs_panic (sb, "some_obscure_error_code");
#endif

This way the system stops with a indication of the failing component
instead of silently corrupting disk contents.  As reiserfs maintains
a log the recovery from that panic shouldn't take that long either.

(On the other hand I've seen some reiserfs systems that destroyed their
 disk contents while trying to recover.  That's a reason why I still
 can't recomend using reiserfs for anything but /tmp, test machines
 or proxy caches).

	Christoph

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

Re: ReiserFS / 2.4.6 / Data Corruption

[Rik van Riel]

On Tue, 31 Jul 2001, Hans Reiser wrote:
> Rik van Riel wrote:
> > On Tue, 31 Jul 2001, Hans Reiser wrote:

> > > 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.

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.

> .. You made the right choice.

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


> 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/

Re: ReiserFS / 2.4.6 / Data Corruption

[Hans Reiser]

Rik van Riel wrote:

> > 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.
> 
> > .. You made the right choice.
> 
> Thanks ;)    [yeah, yeah ... flame me about out-of-context]
> 
> > 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/


A tree is a complex structure.  You can check it, and the temporary structures
involved in balancing it, quite a lot of ways while balancing it.  I believe you
that the checks you need for your code have no significant performance impact. 
Ours sometimes do.  Consistency checks can be quite a bit more than a tad
consumptive of CPU.  Like I said, there were a few checks we removed after the
bug was gone because we got tired waiting for our debugging iterations taking so
long because of them.

Using the #define means we don't have to think about the effect on performance
of a check, we just leave it in.  Some checks belong outside the #define
(checking to see if garbage came back from disk is left outside the define
nowadays.)  Distros should trust the developers in these tradeoff decisions. 
Otherwise, things just get stupid.

Hans

Re: ReiserFS / 2.4.6 / Data Corruption

[Andrew Morton]

Christoph Hellwig wrote:
> 
> For example I've just turned of the debugging on my ext3-using boxens.

FYI...  CONFIG_JBD_DEBUG is really just that - debug stuff.  Mainly,
it enables the printks which are controlled by /proc/sys/fs/jbd-debug.

Early on, sct made the decision that the assertion checks in ext3:

	akpm-1:/usr/src/ext3> grep -r ASSERT . | wc -l
	    187

cannot be disabled.  Each and every one of these will nicely
crash the machine.  The idea being, as you stated earlier,
that data integrity is golden - if we detect an inconsistency
we take the machine out and let recovery fix it up.

Turns out that at present we're over-aggressive on this. A modest
filesytem inconsistency (bit already free in bitmap, whatever)
or an IO error could force a panic.  Stephen is working on changing
the fs to be more selective in its handling of errors - less severe
errors will turn the fs readonly.

I would support your decision to enable reiserfs checking.  It's
a valuable feature.  It can save your data from hardware failures
as well as software failures.  Perhaps Hans' team should look into
moving the expensive checks into a different ifdef.

-

Re: ReiserFS / 2.4.6 / Data Corruption

[Henning P. Schmiedehausen]

Hans Reiser <reiser@namesys.com> writes:

>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     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Re: ReiserFS / 2.4.6 / Data Corruption

[Hans Reiser]

"Henning P. Schmiedehausen" wrote:
> 
> Hans Reiser <reiser@namesys.com> writes:
> 
> >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     hps@intermeta.de
> 
> Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

I stand corrected, this means that all of the distros shipped 2.4 before they
should have.  (I use SuSE 7.2.  I thought that 7.1 had a 2.2 kernel as the
default, but I guess I was wrong.)  

SuSE has its flaws also.  I have complained to them about the yast license, for
instance.  (I think the best single thing they could do for SuSE sales is change
that license.)  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.

Hans

PS

I don't get money from SuSE anymore, I get it from DARPA.  I do run SuSE on my
computer though, which is probably enough to bias me.

Re: ReiserFS / 2.4.6 / Data Corruption

[Arjan van de Ven]

Hans Reiser wrote:
> 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.

In the future, please check your facts more thoroughly. Almost all of
the patches in the Red Hat
2.4.2-2 kernel were bugfixes from later upstream kernel releases.
INCLUDING reiserfs corruption fixes.
Caldera, Suse, Conectiva and Mandrake all do the same. Ok so we all
differ slightly in which bugfixes
each distro picks, and which base version we start with. That's a matter
of taste. And fwiw, 
the 2.4.2-2 Red Hat shipped was closer to 2.4.3-acX than the actual
2.4.2, due to the dozens and 
dozens of bugfixes applied from these newer kernels. (and yes we do test
our kernels. hard. That's 
why we can't recommend reiserfs on anything non Little Endian or 64 bit
right now)

Please take your false conspiracy theories to some place where they are
more appropriate.

Greetings,
   Arjan van de Ven
   Red Hat Linux kernel maintainer

Re: ReiserFS / 2.4.6 / Data Corruption

[Anders Eriksson]

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...

/A

Re: ReiserFS / 2.4.6 / Data Corruption

[Chris Wedgwood]

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

Re: ReiserFS / 2.4.6 / Data Corruption

[Chris Wedgwood]

On Tue, Jul 31, 2001 at 12:24:46PM +0200, Anders Eriksson wrote:

    Side note. I vaguely recall a distribution who's name has escaped
    me since.

OpenBSD?

:)


  --cw

Re: ReiserFS / 2.4.6 / Data Corruption

[Hans Reiser]

Chris Wedgwood wrote:
> 
> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


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.

Hans

Re: ReiserFS / 2.4.6 / Data Corruption

[David Weinehall]

On Tue, Jul 31, 2001 at 02:34:38AM +0400, Hans Reiser wrote:

[snipping earlier discussion]

> 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.

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.


/David
  _                                                                 _
 // David Weinehall <tao@acc.umu.se> /> Northern lights wander      \\
//  Project MCA Linux hacker        //  Dance across the winter sky //
\>  http://www.acc.umu.se/~tao/    </   Full colour fire           </

Re: ReiserFS / 2.4.6 / Data Corruption

[Chris Wedgwood]

On Tue, Jul 31, 2001 at 02:59:46PM +0400, Hans Reiser wrote:

    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 six months time, or whenever people feel more confident about
resierfs stability (there are still many bigs to be found) then these
checks can be relaxed.

Right now, reiserfs is still relatively new --- and its much more
complex and ext2, so having additional sanity checks is a good idea.




  --cw

Re: ReiserFS / 2.4.6 / Data Corruption (patch to cause redhat to unmount reiserfs on halt included)

[Hans Reiser]

David Weinehall wrote:

> > 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.

I didn't say he would agree with me, in fact I am sure he doesn't alike
assertions in the code.  I merely said it should be done.:-)  As a final little
quibble, let me mention that nikita has created macros that neatly hide the
#ifdefs, and sent them out for testing.

We will consider pulling all but the essential assertions out of ReiserFS. 
Sigh.  This is the difference between engineering, and marketing.  As an
engineer, I said overengineer the checks so that our testing process will catch
more things, and then #define them out so that there is no performance cost. 
Perfectly logical.  Then along come the distros, and they turn on debugging,
they don't tell the users that debugging is on, and users think we are slower
than other filesystems when we are just configured exactly as we tell the users
not to configure us, sigh.

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, even more important than recompiling your
kernel, these patches will help.  Note the cute patch that causes reiserfs to
get unmounted rather than unpowered by these folks so concerned about corruption
of data.:-O  I am merely passing these patches onwards, I have not verified that
they are correct (because I lack a redhat machine to test on).  If RedHat could
confirm that the patch is correct it would be nice, and mindboggling as well.

Vitaly, make sure these are on our website.

>From Dustin Byford:

--- rc.sysinit.orig     Mon Jul 30 22:58:45 2001
+++ rc.sysinit  Mon Jul 30 22:57:16 2001
@@ -211,7 +211,8 @@

  _RUN_QUOTACHECK=0
  ROOTFSTYPE=`grep " / " /proc/mounts | awk '{ print $3 }'`
-if [ -z "$fastboot" -a "$ROOTFSTYPE" != "nfs" ]; then
+if [ -z "$fastboot" -a "$ROOTFSTYPE" != "nfs" \
+                    -a "$ROOTFSTYPE" != "reiserfs" ]; then

          STRING=$"Checking root filesystem"
         echo $STRING

>From David Rees:

--- halt.orig   Mon Jul 30 17:26:24 2001
+++ halt        Mon Jul 30 17:26:36 2001
@@ -165,7 +165,7 @@
 
 # Remount read only anything that's left mounted.
 #echo $"Remounting remaining filesystems (if any) readonly"
-mount | awk '/ext2/ { print $3 }' | while read line; do
+mount | awk '/ext2|reiserfs/ { print $3 }' | while read line; do
     mount -n -o ro,remount $line
 done

Re: ReiserFS / 2.4.6 / Data Corruption (patch to cause redhat to unmount reiserfs on halt included)

[Christoph Hellwig]

On Tue, Jul 31, 2001 at 04:22:29PM +0400, Hans Reiser wrote:
> I'll try simply ensuring that users are warned that debugging is on first.

Shouldn't the user be warned when mounting a reiserfs filesystem without
checking instead?

> 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....?

I think you got quite a few facts wrong:

  o when a kernel with non-modular reiserfs is booted, reitherfs is
    loaded before syslogd even starts
  o wether iy hits some logfile, the console or not usually depends on
    the KERN_ prefix you give to reiserfs
  o on Caldera the user won't see any kernel messages unless something
    unexpected happens or he explicitly wants it.

In either case one could rip that message out if there is any gain from it..

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

I am _not_ a reiserfs 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.

I think you got that wrong.  It's really foul to not have checks in that
can prevent silent corruption on a filesystem that is not know for being
very stable.

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

There is no reason why you can't put a reiserfs_nocheck.o module on
your website.  If you want to I can send you a Caldera OpenLinux 3.1
package as reference.

	Christoph

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

Re: ReiserFS / 2.4.6 / Data Corruption (patch to cause redhat to unmount reiserfs on halt included)

[Hans Reiser]

Christoph Hellwig wrote:

> I am _not_ a reiserfs user.
Other Chris.

Re: ReiserFS / 2.4.6 / Data Corruption

[Chris Mason]

On Tuesday, July 31, 2001 02:59:46 PM +0400 Hans Reiser <reiser@namesys.com>
wrote:

[ CONFIG_REISERFS_CHECK ]

> 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

Re: ReiserFS / 2.4.6 / Data Corruption

[Chris Wedgwood]

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.

That way we don't end up with even more #ifdef BLAH / #endif cruft
which obfuscates what is already hard to read code in places!

Flames welcome :)





  --cw

Re: ReiserFS / 2.4.6 / Data Corruption

[Hans Reiser]

Chris Mason wrote:
> 
> On Tuesday, July 31, 2001 02:59:46 PM +0400 Hans Reiser <reiser@namesys.com>
> wrote:
> 
> [ CONFIG_REISERFS_CHECK ]
> 
> > 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.

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.
> 
> 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


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.  

Hans

Re: ReiserFS / 2.4.6 / Data Corruption

[Chris Mason]

On Tuesday, July 31, 2001 07:22:01 PM +0400 Hans Reiser <reiser@namesys.com>
wrote:

> Chris Mason wrote:
>> 
>> On Tuesday, July 31, 2001 02:59:46 PM +0400 Hans Reiser
>> <reiser@namesys.com> wrote:
>> 
>> [ CONFIG_REISERFS_CHECK ]
>> 
>> > 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.
> 
> 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.

It already does.  Read the mount output ;-)

>> 
>> 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
> 
> 
> 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.

If graceful recovery is not possible with CONFIG_REISERFS_CHECK off, the FS
is supposed to panic (or remount readonly).  Anything less is a bug.

CONFIG_REISERFS_CHECK might put the panic in a different place, for example,
it might notice when a block is read in that one of the items is hosed.  That
doesn't mean we can completely ignore hosed items with CONFIG_REISERFS_CHECK
off though.

> (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.

Distributions have methodogies too, its their job to apply it to the products
they ship.  They aren't adding code or breaking existing code, they are
simply enabling one of the options we provide.  If you really don't want
anyone to enable it, it shouldn't be there at all.

> 
> 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.

As per the rules above, this is somewhat true.  I want the FS to be fast as
much as anyone else, but reasonable safety checks are much more important.  

> 
> 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.  
> 

If you can do the check without being slower, why would anyone ever turn it
off?  Speed is not the determining factor in which checks are done, safety is.

-chris

Re: ReiserFS / 2.4.6 / Data Corruption

[Chris Mason]

On Wednesday, August 01, 2001 03:15:54 AM +1200 Chris Wedgwood <cw@f00f.org>
wrote:

> 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.

Two part answer...

1) almost none of the CONFIG_REISERFS_CHECKs look like that, it was an
oversimplified example ;-)

2) Even still, the #ifdefs look nasty, and make the code hard to read.  Take
a look at the latest ac release, which has a patch from Nikita that is
similar to what you describe.

-chris

[OT] Re: ReiserFS / 2.4.6 / Data Corruption

[J Sloan]

Anders Eriksson wrote:

> 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...
>

Rock Linux IIRC -

cu

jjs

Re: ReiserFS / 2.4.6 / Data Corruption

[Jussi Laako]

Rik van Riel wrote:
> 
> If you can chose between sucky performance or a chance
> at silent data corruption ... which would you chose ?

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.

 - Jussi Laako

-- 
PGP key fingerprint: 161D 6FED 6A92 39E2 EB5B  39DD A4DE 63EB C216 1E4B
Available at PGP keyservers

Re: ReiserFS / 2.4.6 / Data Corruption

[Dan Hollis]

On Wed, 1 Aug 2001, Jussi Laako wrote:
> 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.

So if you have a flaky DMA controller, bad cables, etc you will know
instantly. It would at least help catch the 'silent corruption' cases.

-Dan

-- 
[-] Omae no subete no kichi wa ore no mono da. [-]

Re: ReiserFS / 2.4.6 / Data Corruption

[Chris Wedgwood]

On Tue, Jul 31, 2001 at 03:32:39PM -0700, Dan Hollis wrote:

    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.

    So if you have a flaky DMA controller, bad cables, etc you will
    know instantly. It would at least help catch the 'silent
    corruption' cases.

It still doesn't help with block-reordering, the fs needs some way to
communication write-barriers or relative block write ordering to the
lower-levels.

To implement the device, I would hack loopback to take no only the
loopback file, but also another 'checksum' file of 160-bits or
whatever for each 4096 (or whatever) block.  This file might initially
be of zero-length, in which case the bind is responsible for
checksumming the blocks and writing the checksums out on attach.

I say 160-bits (or whatever) so you can use something like SHA1 for
the checksums, this way you can use a small application to resync the
entire fs at the block level over a network without having to read
every block (ie. you compared checksums and then xmit the blocks).
The latter is something I needed a while ago.



  --cw

Re: ReiserFS / 2.4.6 / Data Corruption

[Andreas Dilger]

Jussi Laako writes:
> 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.

Use ext3 then.  It allows full data journaling.  It will even support data
journaling on some files and metadata-only journaling on the rest of the
filesystem (this is currently broken on SMP machines, because not many
people have had a need to use it yet, but it will get fixed).

Cheers, Andreas
-- 
Andreas Dilger  \ "If a man ate a pound of pasta and a pound of antipasto,
                 \  would they cancel out, leaving him still hungry?"
http://www-mddsp.enel.ucalgary.ca/People/adilger/               -- Dogbert

Re: ReiserFS / 2.4.6 / Data Corruption

[Pavel Machek]

Hi!

> > > > 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.
> > 
> > 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

It is better to panic() immediately than "maybe crash" later.

Unless reiserfs is totaly screwed up, CONFIG_CHECKING can not make it *less*
stable -- that's why I understand people turning it on for distributions. Its
*their* choice, not yours.					Pavel
-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

CRC loop method (was Re: ReiserFS / 2.4.6 / Data Corruption)

[Pavel Machek]

Hi!

> > 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.

I have written that. Do you want a copy?

-- 
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.

Re: ReiserFS / 2.4.6 / Data Corruption

[Stephen C. Tweedie]

Hi,

On Fri, Jul 27, 2001 at 02:39:37PM +0100, Alan Cox wrote:

> > I've been doing that most of the time. But I sometimes forget that.
> > But as I said, it's not something I expected from a journalled filesystem.
> 
> You misunderstand journalling then
> 
> A journalling file system can offer different levels of guarantee. With 
> metadata only journalling you don't take any real performance hit but your
> file system is always consistent on reboot (consistent as in fsck would pass
> it) but it makes no guarantee that data blocks got written.

The default behaviour of ext3 does make this guarantee, for what it's
worth.  If you want the more relaxed mode which doesn't enforce the
flushing of data blocks before a commit, you need to mount with "-o
data=writeback".

> Full data journalling will give you what you expect but at a performance hit
> for many applications.

You can achieve the necessary ordering to avoid stale data blocks
after a crash without the penalty of writing all the data to the
journal.

Cheers,
 Stephen

Re: ReiserFS / 2.4.6 / Data Corruption

[Chris Mason]

On Tuesday, July 31, 2001 01:47:25 AM +1000 Andrew Morton <akpm@zip.com.au>
wrote:

> Chris Mason wrote:
>> 
>> On Saturday, July 28, 2001 03:28:05 AM +1000 Andrew Morton
>> <akpm@zip.com.au> wrote:
>> 
>> [ patch to trigger data writes before commit in reiserfs ]
>> 
>> > 
>> > 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...
>> 
>> Well, its gets points for simplicity ;-)
> 
> Well, I tried system("/bin/sync"); but that didn't link.
> 
>> What I think we need is for commit_write to put new buffers a per super
>> list of new buffers, and then the journal code can flush that list on
>> commit.
> 
> whee.  Now there's an idea - If the fs keeps track of all its inodes
> then you can traverse those and flush out the i_dirty_buffers ring
> on each one.

It won't work as well in a generic sense, but I was planning on just using
the b_inode_buffers.  Instead of going onto the inode's dirty buffer list,
they go onto this special list instead (the reiserfs journal already has a
dummy inode used for this).

The advantage is that nothing extra is needed on the buffer head, but the
disadvantage is the buffer doesn't go on the inode's list.  Somebody needs
to flush the new list on fsync and such.  It works for reiserfs, but not in
general.

I think you're right about being able to clear BH_New once get_block tests
it.  Unless someone comes up with a reason against, I'll test it out.  I'm
guessing that we are wasting time rerunning unmap_underlying_metadata on
buffers marked BH_New.

-chris

Re: ReiserFS / 2.4.6 / Data Corruption

[Andrew Morton]

Chris Mason wrote:
> 
> On Saturday, July 28, 2001 03:28:05 AM +1000 Andrew Morton
> <akpm@zip.com.au> wrote:
> 
> [ patch to trigger data writes before commit in reiserfs ]
> 
> >
> > 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...
> 
> Well, its gets points for simplicity ;-)

Well, I tried system("/bin/sync"); but that didn't link.

> What I think we need is for commit_write to put new buffers a per super
> list of new buffers, and then the journal code can flush that list on
> commit.

whee.  Now there's an idea - If the fs keeps track of all its inodes
then you can traverse those and flush out the i_dirty_buffers ring
on each one.

writepage() output is a problem, but that never sits well with
journalling.  I guess one could do fdatasync/fdatawait against
the same list of inodes.

> Since all the filesystems already mark things BH_New, it seems a good
> choice to let commit_write look for BH_New buffers and put them on this new
> list.  But, the only place BH_New seems to get cleared right now is
> unmap_buffer, which only gets called from block_flushpage.
> 
> Is there any reason we can't just clear BH_New before writing the buffer
> out?  It looks like a bug to leave it set the way we do now.

I think it can be cleared as soon as the get_block() caller has looked at
it, actually.  test_and_clear_bit.  The lifecycle of the various buffer_head
fields is exhasperatingly fluffy.

I'd be reluctant to add another eight bytes to buffer_head though.
It's 96 now, which is a nice number.  b_inode can go - it's just
a boolean.  b_size and b_list can be crunched into a single byte..

How about just doing it via the inodes?

-

Re: ReiserFS / 2.4.6 / Data Corruption

[Chris Mason]

On Saturday, July 28, 2001 03:28:05 AM +1000 Andrew Morton
<akpm@zip.com.au> wrote:

[ patch to trigger data writes before commit in reiserfs ]

> 
> 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...

Well, its gets points for simplicity ;-)  

What I think we need is for commit_write to put new buffers a per super
list of new buffers, and then the journal code can flush that list on
commit.

Since all the filesystems already mark things BH_New, it seems a good
choice to let commit_write look for BH_New buffers and put them on this new
list.  But, the only place BH_New seems to get cleared right now is
unmap_buffer, which only gets called from block_flushpage.

Is there any reason we can't just clear BH_New before writing the buffer
out?  It looks like a bug to leave it set the way we do now.

-chris

Re: ReiserFS / 2.4.6 / Data Corruption

[Luigi Genoni]

On Sun, 29 Jul 2001, Chris Wedgwood wrote:

> On Sun, Jul 29, 2001 at 10:15:03PM +1200, Matthew Gardiner wrote:
>
>     tsk tsk tsk. A bit disappointing that Vertias has taken that approach.
>     However, even still, reiserFS is pretty awsome. Extremely fast and space
>     efficient, esp on a 60gig drive ;)
>
> Why "tsk tsk tsk" ?  If reiserfs suits you, use it --- you need never
> go near VXFS.
It depends, for example if you have to manage a farm (let's say 800
systems) with many Unixes
around, where solaris is the 70% of your installed basis, then
veritas (mainly the VM) could be a solution to keep an uniform
environment. That is a good thing if your sysadmin staff is composed also
by people without a real high skill.
>
> Personally, even though I use reiserfs, I am of the opinion that XFS,
> and VXFS and both superior, especially when you include volume
> management.
a journaling filesystem and a volume manager are two complementary
and usefull things, but anyway are  different things.
While i do agree that Linux LVM is still not complitelly usable in a
production environment, (but anyway ELVM from IBM is somehow immmature),
and some details of its design are not completely, how can I say...,
suitable for future HW developments, I found reiserFS tecnology to be
really interesting. On a technological point of view reiserFS is much
more advanced in front of any other journaled FS around.

I still have to see vxfs with Linux, but i saw it under solaris and HP-UX
(i think I used all journaled aroung, jfs, xfs, reiserFS, ext3, vxfs, gfs,
on all unixes i could), seeing it to too much slow on high end scsi HW,
and XFS on my origin 2000 (8 processor) sometimes takes one CPU just to
manage journaling under heavy I/O. Under Linux xfs is maybe better that
under Irix (!!!???), but its tecnology was thinked for other kind of HW,
and an experienced sysadmin can "feel" this.
> Time will show whether or not these very well designed
> file-systems are suitable under Linux though, as reiserfs has a
> considerable head start.
Yes, time will show. reiserFS can have a wonderfull future, better than
ext3 if it will be mature before ext3, worse if after. But for Linux
jfs and xfs are interesting right now, just untill native journaled will
be ready, then i would bet everyone will stay with reiserFS or ext3, not
considering any other solution.

Luigi

Re: ReiserFS / 2.4.6 / Data Corruption

[Christoph Hellwig]

In article <01072902183404.02683@kiwiunixman.nodomain.nowhere> you wrote:
> I've noticed that in the menuconfig there is support for the Vertias 
> Journalling File System. Has there been any push for that to be a "bootable" 
> filesystem so it can be used for Linux?

I don't see any reason wht it shoudn't be bootable, I just haven't tested it
yet.  If you want to try it, please follow the below steps:

1) Get one of these CD-ROM readonly distribution
2) Copy it over NFS to a UnixWare (or any other x86 System with VxFS)
3) Make a VxFS system big enough for the distribution
4) Copy the Distribution on the VxFS filesystem

And now the difficult part:

5) Adjust the ondisk dev_t to match Linux's major/minor split instead
   of SVR4's.  This can either be done by creating (bogus) SVR4 device
   nodes that are valid Linux ones when read by Linux or by doing this
   with fsdb after they were created.

If you have success with this sppropeach please drop me a mail - I'll add
it to the freevxfs docs then.

	Christoph

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

Re: ReiserFS / 2.4.6 / Data Corruption

[Chris Wedgwood]

On Sun, Jul 29, 2001 at 10:15:03PM +1200, Matthew Gardiner wrote:

    tsk tsk tsk. A bit disappointing that Vertias has taken that approach. 
    However, even still, reiserFS is pretty awsome. Extremely fast and space 
    efficient, esp on a 60gig drive ;)

Why "tsk tsk tsk" ?  If reiserfs suits you, use it --- you need never
go near VXFS.

Personally, even though I use reiserfs, I am of the opinion that XFS,
and VXFS and both superior, especially when you include volume
management.  Time will show whether or not these very well designed
file-systems are suitable under Linux though, as reiserfs has a
considerable head start.



  --cw

Re: ReiserFS / 2.4.6 / Data Corruption

[Matthew Gardiner]

On Sunday 29 July 2001 04:25, Alan Cox wrote:
> > I've noticed that in the menuconfig there is support for the Vertias
> > Journalling File System. Has there been any push for that to be a
> > "bootable" filesystem so it can be used for Linux?
>
> The Linux freevxfs module is read only currently. Veritas apparently will
> be releasing the genuine article for Linux but binary only with all the
> mess that entails

tsk tsk tsk. A bit disappointing that Vertias has taken that approach. 
However, even still, reiserFS is pretty awsome. Extremely fast and space 
efficient, esp on a 60gig drive ;)

Matthew Gardiner
-- 
WARNING:

This email was written on an OS using the viral 'GPL' as its license.

Please check with Bill Gates before continuing to read this email/posting.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Re: ReiserFS / 2.4.6 / Data Corruption

[Alan Cox]

> I've noticed that in the menuconfig there is support for the Vertias 
> Journalling File System. Has there been any push for that to be a "bootable" 
> filesystem so it can be used for Linux?

The Linux freevxfs module is read only currently. Veritas apparently will be
releasing the genuine article for Linux but binary only with all the mess
that entails

Re: ReiserFS / 2.4.6 / Data Corruption

[Henning P. Schmiedehausen]

Hans Reiser <reiser@namesys.com> writes:

> Well, I am afraid this is much too vague for me to have any
> understanding of what went wrong on your system.

But you were able on this vagueness of accusing Redhat to "just shovel
software on a CD". Why? Because they didn't give you money unlike some
other vendors, e.g. SuSE?

The thing that really pisses me off about ReiserFS from time to time
is not the "FS" part...

	Regards
		Henning

-- 
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen       -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH     hps@intermeta.de

Am Schwabachgrund 22  Fon.: 09131 / 50654-0   info@intermeta.de
D-91054 Buckenhof     Fax.: 09131 / 50654-20   

Re: ReiserFS / 2.4.6 / Data Corruption

[Matthew Gardiner]

I've noticed that in the menuconfig there is support for the Vertias 
Journalling File System. Has there been any push for that to be a "bootable" 
filesystem so it can be used for Linux?

Matthew Gardiner
-- 
WARNING:

This email was written on an OS using the viral 'GPL' as its license.

Please check with Bill Gates before continuing to read this email/posting.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Re: ReiserFS / 2.4.6 / Data Corruption

[Matthew Gardiner]

On Saturday 28 July 2001 01:39, Alan Cox wrote:
> > > Putting a sync just before the insmod when developing new drivers is a
> > > good idea btw
> >
> > I've been doing that most of the time. But I sometimes forget that.
> > But as I said, it's not something I expected from a journalled
> > filesystem.
>
> You misunderstand journalling then
>
> A journalling file system can offer different levels of guarantee. With
> metadata only journalling you don't take any real performance hit but your
> file system is always consistent on reboot (consistent as in fsck would
> pass it) but it makes no guarantee that data blocks got written.
>
> Full data journalling will give you what you expect but at a performance
> hit for many applications.
>
> Alan

Just in regards to full journalling, will/is there an option in ReiserFS to 
allow it? Personally, I would much rather have full journalling, and a little 
more of a performance hit for security and reliability, than great 
performance and a higher level of risk.

Matthew Gardiner
-- 
WARNING:

This email was written on an OS using the viral 'GPL' as its license.

Please check with Bill Gates before continuing to read this email/posting.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Re: ReiserFS / 2.4.6 / Data Corruption

[Chris Mason]

On Saturday, July 28, 2001 11:36:33 AM +0400 Hans Reiser <reiser@namesys.com>
wrote:

> Alan Cox wrote:
>> 
>> No doubt if Namesys ran test suites all the tail merging bug fiasco and the
>> directory/tree balance races wouldnt have happened.
> Our test suites need much improvement, but we do have them and use them.
> Can you say the same?

He's already described some of the testing they do.  I would suggest there
are better ways to use l-k bandwidth than picking a fight with redhat,
especially on topics that have already been beaten to death.  

Alan, thanks for helping to test the reiserfs patches we've been sending to
in the ac tree, we do appreciate it.

-chris

Re: ReiserFS / 2.4.6 / Data Corruption

[Hans Reiser]

Alan Cox wrote:
> 
> > By the way, how about considering the use of tests before redhat coders put stuff in the linux
> > kernel?  You know, if VFS changes actually got tested before users encountered things like Viro
> > breaking ReiserFS in 2.4.5, it would be nice.
> > At Namesys, like all normal software shops, we actually run a test suite before shipping code
> > externally.  We usually try to require that it be tested by at least one person in addition to the
> > code author.
> 
> *PLONK*
> 
> No doubt if Namesys ran test suites all the tail merging bug fiasco and the
> directory/tree balance races wouldnt have happened.
Our test suites need much improvement, but we do have them and use them.  Can you say the same?

Hans

Re: ReiserFS / 2.4.6 / Data Corruption

[Alan Cox]

> By the way, how about considering the use of tests before redhat coders put stuff in the linux
> kernel?  You know, if VFS changes actually got tested before users encountered things like Viro
> breaking ReiserFS in 2.4.5, it would be nice.
> At Namesys, like all normal software shops, we actually run a test suite before shipping code
> externally.  We usually try to require that it be tested by at least one person in addition to the
> code author.

*PLONK*

No doubt if Namesys ran test suites all the tail merging bug fiasco and the
directory/tree balance races wouldnt have happened.

Re: ReiserFS / 2.4.6 / Data Corruption

[Hans Reiser]

Alan Cox wrote:
> 
> > Let us be a bit more precise here.  If you click on the help button when deciding whether to select
> > that option it tells you not to do it.  What can you say about a distro that doesn't read the help
> > buttons for the kernel options when configuring the kernel?  Shovelware?
> 
> The alternative was to disable it. Because at the time we had lots of good
> evidence it didnt work reliably. Evidence backed up by the pile of later
> Chris Mason patches.
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Better to disable it than to cripple it.

By the way, how about considering the use of tests before redhat coders put stuff in the linux
kernel?  You know, if VFS changes actually got tested before users encountered things like Viro
breaking ReiserFS in 2.4.5, it would be nice.

At Namesys, like all normal software shops, we actually run a test suite before shipping code
externally.  We usually try to require that it be tested by at least one person in addition to the
code author.

It would catch things like your gcc problems.  Test suites don't catch everything, but they are
considered the responsible thing to do at most places.

Hans

Re: ReiserFS / 2.4.6 / Data Corruption

[Alan Cox]

> Let us be a bit more precise here.  If you click on the help button when deciding whether to select
> that option it tells you not to do it.  What can you say about a distro that doesn't read the help
> buttons for the kernel options when configuring the kernel?  Shovelware?

The alternative was to disable it. Because at the time we had lots of good
evidence it didnt work reliably. Evidence backed up by the pile of later
Chris Mason patches.

Re: ReiserFS / 2.4.6 / Data Corruption

[Hans Reiser]

"pcg( Marc)"@goof(A.).(Lehmann )com wrote:

> > No. The only thing I can think of that might slow it is that we build with
> > the reiserfs paranoia/sanity checks on.
> 
> That's a pretty dumb thing. Maybe one should have asked the develoers
> before doing this (they never do). Redhat somehow manages pretty well to
> show reiserfs in a bad light ;)

Let us be a bit more precise here.  If you click on the help button when deciding whether to select
that option it tells you not to do it.  What can you say about a distro that doesn't read the help
buttons for the kernel options when configuring the kernel?  Shovelware?

Hans

Re: ReiserFS / 2.4.6 / Data Corruption

[Lehmann]

On Fri, Jul 27, 2001 at 04:06:16PM +0100, Alan Cox <alan@lxorguk.ukuu.org.uk> 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.
> 
> Sorry Hans you can rant all you like but you know you are wrong on most
> of that. RH did weeks of stress testing on multiple systems up to 8Gb 8 way
> and didn't ship until we stopped seeing corruption problems with the mm/fs
> code. 

You might be well advised looking at reality (visit a few other projects)
and you'll see that redhat, indeed, has a very bad reputation. Wether it's
gimp, gtk, perl, wine, dosemu or any other project, the basic reaction is:
oh, you have gt problems under redhat? you compile it yourself and most
probably your problems will go away (gtk+ even had this message in their
install script).

> That test suite caught bugs in kernel revisions other vendors shipped
> blindly to their customers without fixing.

they might have a very good testsuite, but that means nothing: redhat
so frequently takes snapshots of undebugged alpha versions of software
(higher version numbers) that no matter of testing will suffice to ever
make this work.

the might be doing well for the kernel, but that only gets you so far.

> That is hardly shovelling software onto the CD.

Right, that's shovelling the latest alpha versions of software onto CD.

> > Actually, I am curious as to exactly how they manage to make ReiserFS boot longer than ext2.  Do
> > they run fsck or what?
> No. The only thing I can think of that might slow it is that we build with
> the reiserfs paranoia/sanity checks on.

That's a pretty dumb thing. Maybe one should have asked the develoers
before doing this (they never do). Redhat somehow manages pretty well to
show reiserfs in a bad light ;)

However, ext2 is much faster on mount time with -onocheck (instantaneous);
and for all current harddisk sizes ext2 is somewhat to much slower on
mount. And yes, the redhat init system (just like suse's or most others,
of course) is sooo slow that improving the init system will have a much
larger effect than the ext2/reiserfs differences.

(So trying to improve this in the kernel would be the wrong place to
start).

-- 
      -----==-                                             |
      ----==-- _                                           |
      ---==---(_)__  __ ____  __       Marc Lehmann      +--
      --==---/ / _ \/ // /\ \/ /       pcg@goof.com      |e|
      -=====/_/_//_/\_,_/ /_/\_\       XX11-RIPE         --+
    The choice of a GNU generation                       |
                                                         |

Re: ReiserFS / 2.4.6 / Data Corruption

[Hans Reiser]

Dustin Byford wrote:

> Also, one purely cosmetic patch to rc.sysinit if you want:
> --- rc.sysinit.orig Fri Jul 27 13:06:58 2001
> +++ rc.sysinit Fri Jul 27 13:38:25 2001
> @@ -211,7 +211,8 @@
> 
> _RUN_QUOTACHECK=0
> ROOTFSTYPE=`grep " / " /proc/mounts | awk '{ print $3 }'`
> -if [ -z "$fastboot" -a "$ROOTFSTYPE" != "nfs" ]; then
> +if [ -z "$fastboot" -a "$ROOTFSTYPE" != "nfs" \
> + -a "$ROOTFSTYPE" != "reiserfs" ]; then
> 
> STRING=$"Checking root filesystem"
> echo $STRING


Yes, this patch is much needed.  Edward, put it on our website in an appropriate location.

Hans

Re: ReiserFS / 2.4.6 / Data Corruption

[Dustin Byford]

Hans Reiser wrote:

> Maybe somebody else who is using both ReiserFS and RedHat's boot scripts can comment on whether
> things are slow for them and if so, where they get slow.


For what it's worth I just configured a RedHat 7.1 box with reiserfs on 
all partitions except /boot using this update disk 
ftp://139.82.28.40/pub/update-rh71reiser-v1.img from 
http://cambuca.ldhs.cetuc.puc-rio.br/.

Upgraded all of redhat's packages, note there is a SysVinit update and a 
gcc update.

Compiled a 2.4.7-pre kernel and the latest reiserfsprogs.

Mounted /boot read only to eliminate the chance of an fsck required on 
that partition.

I have been running reiserfs on a mail server with about 60k accounts 
(30k really active) for about 6 months. I haven't experienced any 
problems with the filesystems. The one I just configured is its intended 
replacment. After a few days of testing with bonnie, some perl scripts I 
wrote, and a few pullings of the power cord I think it's almost ready 
for production. An upgrade to 2.4.7 and some more testing will tell.

If you pull the plug on this machine it takes around 40 seconds to get 
back to the login prompt, (p3-600 60G ide drive). Including the act of 
pulling the power cord, bios delays, lilo delays, and the rest of the 
redhat boot sequence.

So, in my experience I've had very few problems with reiserfs and 
redhat. That said, the slightest hint of data corruption under normal 
(continuous power, no failing hardware) operation and I'll probably be 
evaluating other filesystems. There are sometimes as many as 500,000 
files on this filesystem, reiserfs seems to do a good job under my 
conditions.

				--Dustin

Also, one purely cosmetic patch to rc.sysinit if you want:
--- rc.sysinit.orig Fri Jul 27 13:06:58 2001
+++ rc.sysinit Fri Jul 27 13:38:25 2001
@@ -211,7 +211,8 @@

_RUN_QUOTACHECK=0
ROOTFSTYPE=`grep " / " /proc/mounts | awk '{ print $3 }'`
-if [ -z "$fastboot" -a "$ROOTFSTYPE" != "nfs" ]; then
+if [ -z "$fastboot" -a "$ROOTFSTYPE" != "nfs" \
+ -a "$ROOTFSTYPE" != "reiserfs" ]; then

STRING=$"Checking root filesystem"
echo $STRING

Re: ReiserFS / 2.4.6 / Data Corruption

[Hans Reiser]

Christoph Rohland wrote:
> 
> Hi Hans,
> 
> On Fri, 27 Jul 2001, Hans Reiser wrote:
> > Maybe somebody else who is using both ReiserFS and RedHat's boot
> > scripts can comment on whether things are slow for them and if so,
> > where they get slow.
> 
> At least not if it's not the root disk. I have a RH71 box with a 19GB
> reiserfs partition and it's booting fast and fine.
> 
> Greetings
>                 Christoph
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Ok, well then I conclude that it was a user misdiagnosis as to what his booting problem was of some
unknowable form.

Apologies to RedHat.

Hans

Re: ReiserFS / 2.4.6 / Data Corruption

[Christoph Rohland]

Hi Hans,

On Fri, 27 Jul 2001, Hans Reiser wrote:
> Maybe somebody else who is using both ReiserFS and RedHat's boot
> scripts can comment on whether things are slow for them and if so,
> where they get slow.

At least not if it's not the root disk. I have a RH71 box with a 19GB
reiserfs partition and it's booting fast and fine.

Greetings
		Christoph

Re: ReiserFS / 2.4.6 / Data Corruption

[Ville Herva]

On Fri, Jul 27, 2001 at 06:40:32PM +0100, you [Alan Cox] claimed:
> > After fresh boot to the default RH71 kernel (2.4.2-2 or whatever it is) on
> > console (no X running):
> > 
> > > diff -Naur /usr/src/linux.rh-default /usr/src/linux-2.4.4 > diff
> > zsh: killed diff
> > 
> > > dmesg | tail
> > kernel: out of memory, killed process n (xfs)
> > kernel: out of memory, killed process n (diff)
> > 
> > Phew.
> 
> No argument on that one. I'm still seeing it in vanilla 2.4.6 as well but
> 2.4.7 is looking a lot better. 

I wasn't able to easily reproduce that on 2.4.4ac5 (that I upgraded into
almost immediately). It may be that the OOM rambo wasn't fully sane on that
one either, but at least it seemed to handle the silly "someone filled the
cache - gee, we must be oom" case rather better...


-- v --

v@iki.fi

Re: ReiserFS / 2.4.6 / Data Corruption

[Alan Cox]

> After fresh boot to the default RH71 kernel (2.4.2-2 or whatever it is) on
> console (no X running):
> 
> > diff -Naur /usr/src/linux.rh-default /usr/src/linux-2.4.4 > diff
> zsh: killed diff
> 
> > dmesg | tail
> kernel: out of memory, killed process n (xfs)
> kernel: out of memory, killed process n (diff)
> 
> Phew.

No argument on that one. I'm still seeing it in vanilla 2.4.6 as well but
2.4.7 is looking a lot better. 

Re: ReiserFS / 2.4.6 / Data Corruption

[Ville Herva]

On Fri, Jul 27, 2001 at 09:25:23AM -0700, you [Kip Macy] claimed:
>  
> sys_write was failing with ENOMEM (on a machine with 1GB of RAM that was 
> not doing anything else).

I second that.

256M memory, no swap at the time.

After fresh boot to the default RH71 kernel (2.4.2-2 or whatever it is) on
console (no X running):

> diff -Naur /usr/src/linux.rh-default /usr/src/linux-2.4.4 > diff
zsh: killed diff

> dmesg | tail
kernel: out of memory, killed process n (xfs)
kernel: out of memory, killed process n (diff)

Phew.


-- v --

v@iki.fi

Re: ReiserFS / 2.4.6 / Data Corruption

[Alan Cox]

> > Alan
> big endian support is resolved, there is a working patch for it by Jeff Mahoney, it passes all of
> our tests, but it is a feature not a bug fix, and not something for a supposedly stabilizing kernel.
> 
> Nikita, you were supposed to send the big endian support and some other stuff in to Alan for testing
> in the ac series, what is the status of patches that are supposed to be going to Alan?

I suspect its a bug fix to S/390, ppc and sparc users 8)

I'd be happy to test run it in -ac

Re: ReiserFS / 2.4.6 / Data Corruption

[Hans Reiser]

Alan Cox wrote:

> Nobody needs conspiracies to not use reiserfs as their core fs, and until
> things like big endian support are cleanly resolved that isnt likely to
> change.
> 
> Alan
big endian support is resolved, there is a working patch for it by Jeff Mahoney, it passes all of
our tests, but it is a feature not a bug fix, and not something for a supposedly stabilizing kernel.

Nikita, you were supposed to send the big endian support and some other stuff in to Alan for testing
in the ac series, what is the status of patches that are supposed to be going to Alan?

Hans

Re: ReiserFS / 2.4.6 / Data Corruption

[Kip Macy]

> Alan Cox 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.
> > 
> > Sorry Hans you can rant all you like but you know you are wrong on most
> > of that. RH did weeks of stress testing on multiple systems up to 8Gb 8 way
> > and didn't ship until we stopped seeing corruption problems with the mm/fs
> > code.

Sorry Alan, but even though I am sure Redhat did lots of stress testing,
Redhat 7.1 was not a particularly solid release. I got oopses in the
eepro100 driver even though lots of other people use it, and the netapp
simulator which works just fine on 2.2.16 does not work on it. When I ran
strace on the simulator while it was zeroing some files it turned out that
sys_write was failing with ENOMEM (on a machine with 1GB of RAM that was 
not doing anything else).

Re: ReiserFS / 2.4.6 / Data Corruption

[Alan Cox]

> > No. The only thing I can think of that might slow it is that we build with
> > the reiserfs paranoia/sanity checks on. Thats because at the time 7.1 was
> 
> Yes, that option should never be on for an end user not having a bug that he wants a more detailed
> bug report on.  It just makes us look slow compared to ext2.

Maybe its old fashioned but we'd rather any inconsistency in the file system
behaviour was made obvious to the end user. Enterprise customers object to
losing data.

> 2.4.2 was not a stable kernel for any FS, not just for ReiserFS.

The RH 2.4.2 derived kernel isnt 2.4.2 by any stretch of the imagination. 
Vanilla 2.4.2 wouldnt pass a test suite.

> I don't think that even with CONFIG_REISERFS_CHECK on, journal replay can take as long as fsck on
> ext2.  reiserfsck though, if that was on, oh, could even RedHat be that desperate to make us look
> bad to users as to run reiserfsck at every boot?

Hans, if you stopped considering every report that your file system wasn't
the best in the world as either a conspiracy theory or someone elses fault
you'd have a much better product

Nobody needs conspiracies to not use reiserfs as their core fs, and until
things like big endian support are cleanly resolved that isnt likely to
change.

Alan

Re: ReiserFS / 2.4.6 / Data Corruption

[Hans Reiser]

Well, I am afraid this is much too vague for me to have any understanding of what went wrong on your
system.

Maybe somebody else who is using both ReiserFS and RedHat's boot scripts can comment on whether
things are slow for them and if so, where they get slow.

With this lack of specificity is entirely possible that things went slow for coincidental reasons
unrelated to ReiserFS (waiting for network stuff to timeout, etc.)

Hans

Joshua Schmidlkofer wrote:
> 
> On Friday 27 July 2001 09:06 am, Alan Cox 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.
> >
> > Sorry Hans you can rant all you like but you know you are wrong on most
> > of that. RH did weeks of stress testing on multiple systems up to 8Gb 8 way
> > and didn't ship until we stopped seeing corruption problems with the mm/fs
> > code.
> >
> > That test suite caught bugs in kernel revisions other vendors shipped
> > blindly to their customers without fixing.
> >
> > That is hardly shovelling software onto the CD.
> >
> > > Actually, I am curious as to exactly how they manage to make ReiserFS
> > > boot longer than ext2.  Do they run fsck or what?
> >
> > No. The only thing I can think of that might slow it is that we build with
> > the reiserfs paranoia/sanity checks on. Thats because at the time 7.1 was
> > done the kernel list was awash with reiserfs bug reports and Chris Mason
> > tail recursion bug patch of the week.
> >
> > That might be something to check to get a fair comparison
> 
>    I feel that things are actually progressing above my level of perception
> here, however, I would like to mention that since my Redhat 4.x days i have
> feared vendor kernels, and I never use them, for better or worse.
> 
>     Also, maybe I screwed my own system - I don't think so, but maybe.  I
> prefer to stick with Linus's kernels, and sometimes, depending on the
> changlog -ac kernels.  As far as the kernel & init scirpts are concerned, I
> axed any fsck'ing entries for reiserfs.   [I assume that they were
> unnessecary.]  I used kgcc [w/Rh7.1] to compile kernels, until recently.  And
> I stayed current with the lkml, and the namesys page watching for obvious
> updates that I needed.
> 
>     The slowness [seemed] actually [to be] the process of starting & stopping
> daemons.  Almost like there was some sort of stigma about reading shell
> scripts.  All the binaries executed with appropriate haste.
> 
>    As far as shoveling code.   Sometimes the options used to compile packages
> leaves me with a large bit of wonder.  Strange and seemingly heinous changes
> to the various utilities, etc.   But, I have never had a cause to fault them
> based on this. [Except that I have never found the magic that causes all the
> SRPMS to be [re]buildable.]
> 
>   So to sort it, I don't feel that being a moron caused to boot slow - unless
> there is some wierd filehandling problem in bash2, or something that causes
> severe slow-down when sourcing shell scripts.  ????   However, Hans, I do
> beleive you about Suse, and if I wasn't a cheap bastard I would probably buy
> a copy.
> 
> thanks for all the response, and I am sorry if this does not belong here.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: ReiserFS / 2.4.6 / Data Corruption

[Hans Reiser]

Alan Cox 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.
> 
> Sorry Hans you can rant all you like but you know you are wrong on most
> of that. RH did weeks of stress testing on multiple systems up to 8Gb 8 way
> and didn't ship until we stopped seeing corruption problems with the mm/fs
> code.
> 
> That test suite caught bugs in kernel revisions other vendors shipped
> blindly to their customers without fixing.
> 
> That is hardly shovelling software onto the CD.
> 
> > Actually, I am curious as to exactly how they manage to make ReiserFS boot longer than ext2.  Do
> > they run fsck or what?
> 
> No. The only thing I can think of that might slow it is that we build with
> the reiserfs paranoia/sanity checks on. Thats because at the time 7.1 was

Yes, that option should never be on for an end user not having a bug that he wants a more detailed
bug report on.  It just makes us look slow compared to ext2.

2.4.2 was not a stable kernel for any FS, not just for ReiserFS.

2.4.4 was the earliest kernel that should have been called 2.4.0, and sad to say, I bet we won't hit
a really stable kernel for another couple of versions.

I understand the marketing pressure on distributions to ship using 2.4.x as soon as 2.4.0 was
available, and that pressure should never have been generated upon them by making an unstable kernel
be named 2.4.0.

It won't surpise me if you agree with me on the kernel naming though, and if so it is pointless for
me to complain to you about it. 

> done the kernel list was awash with reiserfs bug reports and Chris Mason
> tail recursion bug patch of the week.
> 
> That might be something to check to get a fair comparison
> 
> Alan

I don't think that even with CONFIG_REISERFS_CHECK on, journal replay can take as long as fsck on
ext2.  reiserfsck though, if that was on, oh, could even RedHat be that desperate to make us look
bad to users as to run reiserfsck at every boot?

I surely hope not, and I'd like to hear that this user just had something individually wrong with
his configuration.

Hans

Re: ReiserFS / 2.4.6 / Data Corruption

[Joshua Schmidlkofer]

On Friday 27 July 2001 09:06 am, Alan Cox 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.
>
> Sorry Hans you can rant all you like but you know you are wrong on most
> of that. RH did weeks of stress testing on multiple systems up to 8Gb 8 way
> and didn't ship until we stopped seeing corruption problems with the mm/fs
> code.
>
> That test suite caught bugs in kernel revisions other vendors shipped
> blindly to their customers without fixing.
>
> That is hardly shovelling software onto the CD.
>
> > Actually, I am curious as to exactly how they manage to make ReiserFS
> > boot longer than ext2.  Do they run fsck or what?
>
> No. The only thing I can think of that might slow it is that we build with
> the reiserfs paranoia/sanity checks on. Thats because at the time 7.1 was
> done the kernel list was awash with reiserfs bug reports and Chris Mason
> tail recursion bug patch of the week.
>
> That might be something to check to get a fair comparison

   I feel that things are actually progressing above my level of perception 
here, however, I would like to mention that since my Redhat 4.x days i have 
feared vendor kernels, and I never use them, for better or worse.   

    Also, maybe I screwed my own system - I don't think so, but maybe.  I 
prefer to stick with Linus's kernels, and sometimes, depending on the 
changlog -ac kernels.  As far as the kernel & init scirpts are concerned, I 
axed any fsck'ing entries for reiserfs.   [I assume that they were 
unnessecary.]  I used kgcc [w/Rh7.1] to compile kernels, until recently.  And 
I stayed current with the lkml, and the namesys page watching for obvious 
updates that I needed. 

    The slowness [seemed] actually [to be] the process of starting & stopping 
daemons.  Almost like there was some sort of stigma about reading shell 
scripts.  All the binaries executed with appropriate haste.

   As far as shoveling code.   Sometimes the options used to compile packages 
leaves me with a large bit of wonder.  Strange and seemingly heinous changes 
to the various utilities, etc.   But, I have never had a cause to fault them 
based on this. [Except that I have never found the magic that causes all the 
SRPMS to be [re]buildable.]

  So to sort it, I don't feel that being a moron caused to boot slow - unless 
there is some wierd filehandling problem in bash2, or something that causes 
severe slow-down when sourcing shell scripts.  ????   However, Hans, I do 
beleive you about Suse, and if I wasn't a cheap bastard I would probably buy 
a copy.  

thanks for all the response, and I am sorry if this does not belong here.

RE: ReiserFS / 2.4.6 / Data Corruption

[Cress, Andrew R]

-----Original Message-----
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.
[...]
>Chris Wedgewood wrote:
>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.
---
Yes, I would be very interested in a tips/HOWTO on how to fix the compile
options, boot scripts, etc. for RedHat 7.1.  I've been struggling with a
software RAID1 configuration with reiserfs on root and Redhat 7.1.  

Andy Cress

Re: ReiserFS / 2.4.6 / Data Corruption

[Philip R. Auld]

Hans Reiser wrote:
> 
> "Philip R. Auld" wrote:
> 
> > reiserfs with full data logging enabled of course does not show this behavior
> > (and works really well if you are willing to take the performance hit).
> 
> Hmmm, I didn't realize this had made off our wish list and into the code.:)
> We should benchmark the cost to performance.
> 
> Hans

Ooops, hope I'm not getting Chris in trouble ;)

This is reiserfs 3.5.33, with a few changes from Chris to enable full logging, 
and from me to make it a mount option. 

We are in a situation where we need the safety more than the speed so it was
necessary.


Here is a simple comparison using bonnie:

              -------Sequential Output-------- ---Sequential Input-- --Random--
              -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
Machine    MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU  /sec %CPU
pblade 1 (reiserfs defaults)
         1000 13048 98.9 21609 27.4  6599 10.7 11066 72.3 16483  8.4 1011.2  5.3 
	 1000 12771 96.7 21058 25.9  5536  9.0 10430 67.5 17347  8.4 1065.2  6.7 
	 1000 13034 98.6 19746 21.6  7026 11.6  9884 64.4 14838  7.2 1106.0  9.7
         1000 13091 99.3 19483 28.9  7586 12.3 10520 68.4 14685  6.9  900.9  6.3
pblade 2 (ext2 defaults)
         1000 14373 99.9 14940  8.8  7494 11.1 10093 65.3 22213  9.3 1028.3 
6.4      
	 1000 14305 99.6 16129  9.4  7768 11.9  9629 62.2 26108 10.8 1135.8  7.7    
	 1000 14400 99.9 16769  9.8  7397 11.2  9805 63.4 21820  9.1 1139.8  5.7
	 1000 14361 100. 17089 10.4  7768 11.5  9924 64.1 24154  9.8 1112.9  7.2
pblade 3 (log all data)
	 1000  5932 47.6  7244 12.5  4708  9.7 13909 90.5 17051  8.1 894.5  6.5
	 1000  5839 46.9  7229 12.5  4604  9.9 13437 87.9 19852  9.7 724.3  4.7
	 1000  5853 47.0  7176 12.3  4611  9.8 13995 91.1 18838  8.7 908.0  5.7
	 1000  5604 45.1  7106 12.2  4627  9.5 13628 88.6 15248  6.9 882.9  6.6
pblade 6 ( log new data )
	 1000  5556 49.0  7057 11.9  7714 12.6 11559 92.8 18075  8.8 1264.3  7.3    
	 1000  5631 49.8  7307 12.3  7945 13.0 11558 93.0 18859  9.0 1230.7  8.0
	 1000  5610 49.6  7337 12.5  6620 11.0 11821 95.0 16484  7.5 1236.8  9.3
	 1000  5592 49.4  7070 12.1  7422 12.0 11575 92.9 16198  7.3 1236.6  4.9


I suugest we move this to reiserfs-list for more discussion if needed :)


Cheers,

Phil


------------------------------------------------------
Philip R. Auld, Ph.D.                  Technical Staff 
Egenera Corp.                        pauld@egenera.com
165 Forest St, Marlboro, MA 01752        (508)786-9444

Re: ReiserFS / 2.4.6 / Data Corruption

[Alan Cox]

> 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.

Sorry Hans you can rant all you like but you know you are wrong on most
of that. RH did weeks of stress testing on multiple systems up to 8Gb 8 way
and didn't ship until we stopped seeing corruption problems with the mm/fs
code. 

That test suite caught bugs in kernel revisions other vendors shipped
blindly to their customers without fixing.

That is hardly shovelling software onto the CD.

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

No. The only thing I can think of that might slow it is that we build with
the reiserfs paranoia/sanity checks on. Thats because at the time 7.1 was
done the kernel list was awash with reiserfs bug reports and Chris Mason
tail recursion bug patch of the week.

That might be something to check to get a fair comparison

Alan

Re: ReiserFS / 2.4.6 / Data Corruption

[Hans Reiser]

"Philip R. Auld" wrote:
 
> reiserfs with full data logging enabled of course does not show this behavior
> (and works really well if you are willing to take the performance hit).

Hmmm, I didn't realize this had made off our wish list and into the code.:)
We should benchmark the cost to performance.

Hans

Re: ReiserFS / 2.4.6 / Data Corruption

[Jordan]

"Philip R. Auld" wrote:
> 
> Alan Cox wrote:
> >
> > Its certainly a good idea. But it sounds to me like he is describing the
> > normal effect of metadata only logging.
> >
> 
> Which brings up something I have been struggling with lately:
> 
> Linux (using both ext2 and reiserfs) can show garbage data blocks at the end of
> files after a crash. With reiserfs this is clearly due to metadata only logging
> and happens say 3 out of 5 times. With ext2 the frequency is about 1 in 5 times,
> and more often that not it is simply zeroed data. Sometimes it is old data
> though.
> 
> This is something that is not present in other unix filesystems as far as I can
> tell. If linux wants to be used in enterprise sites we can't allow
> old data blocks to be read. And ideally shouldn't allow zero blocks to be seen
> either, but this is somewhat less serious.
> 
> I cannot reproduce this in ufs on either freebsd or solaris8.
> 
> I have not tested it with xfs and jfs for linux yet (and don't have any native
> systems at hand.)
> 
> I believe vxfs to have a mechanism to prevent this despite metadata only
> logging.
> 
> reiserfs with full data logging enabled of course does not show this behavior
> (and works really well if you are willing to take the performance hit).
> 
> The basic test I use is to run this perl script for a while (to make sure at
> least somehting has had a chance to get written out) and then power-cycle the
> machine. When it comes back a simple tail logfile will show the problem. I also
> run bonnie before hand to fill the disk with a known pattern so its easier to
> spot.
> 
> linux is 2.2.16 and 2.4.2 from redhat 7.1. reiserfs is 3.5.33 and was tested
> only on 2.2.16.
> 
> #!/usr/bin/perl
> use Fcntl;
> $count = 0;
> while (1) {
> #sysopen(FH, "/scratch/logfile", O_RDWR|O_APPEND|O_CREAT|O_SYNC)
> sysopen(FH, "/scratch/logfile", O_RDWR|O_APPEND|O_CREAT)
>         or die "Couldn't open file $path : $!\n";
> print FH "Log file line ", $count , " yadda  yadda  yadda  yadda  yadda  yadda
> yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda
> yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda
> yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda
> yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda
> yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda
> yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda
> yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda
> yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda
> yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda \n" ;
> close (FH);
> #print $count , "\n";
> $count++;
> }
> 
> ------------------------------------------------------
> Philip R. Auld, Ph.D.                  Technical Staff
> Egenera Corp.                        pauld@egenera.com
> 165 Forest St, Marlboro, MA 01752        (508)786-9444
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

I didn't know that there was a way to enable full data journaling using
reiserfs.  I was under the impression that with the latest round of the
unlink patch to go with 2.4.7 that reiserfs was basically in ordered
journaling mode instead of writeback (I believe that is the name), if I
am wrong or if there really is a way to enable full data journaling
please let me know.  Thanks.

Jordan

Re: ReiserFS / 2.4.6 / Data Corruption

[Hans Reiser]

Alan Cox wrote:
> 
> > > 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?
> 
> Its certainly a good idea. 
I think it is a terrible idea.... at least as a general expectation to meet, there may be specifics
where things can be done though.... like journaling....

> But it sounds to me like he is describing the
> normal effect of metadata only logging.

Ah, right you are.  Now I understand him.  Well, data-journaling that doesn't cost a whole lot of
performance awaits reiser4, and reiser4 is at least a year away, we are doing seminars and
pseudo-coding now.

> 
> Putting a sync just before the insmod when developing new drivers is a good
> idea btw

This makes a lot of sense to me.  Good suggestion.  It should go into our FAQ.  Dad, please put it
there.

Q: I like to dynamically load buggy drivers into the kernel because that is what kernel developers
like me do for fun, how can I better avoid data corruption when doing this and using ReiserFS?

A: Do sync before insmod.  (Alan Cox's good suggestion.)

Re: ReiserFS / 2.4.6 / Data Corruption

[Alan Cox]

> This is something that is not present in other unix filesystems as far as I can
> tell. If linux wants to be used in enterprise sites we can't allow 
> old data blocks to be read. And ideally shouldn't allow zero blocks to be seen
> either, but this is somewhat less serious.

> I cannot reproduce this in ufs on either freebsd or solaris8.

It can happen on UFS. What normally happens on UFS is that you get an old
file attached to a new filename when the file is deleted and the inode
reused.

Basically it can happen on any no data logging fs (with a few exceptions for
other clever algorithms like tree-phase)

If you write the metadata block first (UFS) then there is a risk of getting
someone elses data appended to the end of a file (eg length updated before
data blocks). If you write data first there is a risk of writing the data
and never committing the removal of the block from previous files.

FreeBSD softupdates probably make it very hard to trigger and they are a
very nice approach

Re: ReiserFS / 2.4.6 / Data Corruption

[Philip R. Auld]

Alan Cox wrote:
> 
> Its certainly a good idea. But it sounds to me like he is describing the
> normal effect of metadata only logging.
> 

Which brings up something I have been struggling with lately:

Linux (using both ext2 and reiserfs) can show garbage data blocks at the end of
files after a crash. With reiserfs this is clearly due to metadata only logging
and happens say 3 out of 5 times. With ext2 the frequency is about 1 in 5 times,
and more often that not it is simply zeroed data. Sometimes it is old data
though. 


This is something that is not present in other unix filesystems as far as I can
tell. If linux wants to be used in enterprise sites we can't allow 
old data blocks to be read. And ideally shouldn't allow zero blocks to be seen
either, but this is somewhat less serious.

I cannot reproduce this in ufs on either freebsd or solaris8.

I have not tested it with xfs and jfs for linux yet (and don't have any native
systems at hand.)

I believe vxfs to have a mechanism to prevent this despite metadata only
logging.

reiserfs with full data logging enabled of course does not show this behavior
(and works really well if you are willing to take the performance hit).

The basic test I use is to run this perl script for a while (to make sure at
least somehting has had a chance to get written out) and then power-cycle the
machine. When it comes back a simple tail logfile will show the problem. I also
run bonnie before hand to fill the disk with a known pattern so its easier to
spot.

linux is 2.2.16 and 2.4.2 from redhat 7.1. reiserfs is 3.5.33 and was tested
only on 2.2.16.


#!/usr/bin/perl
use Fcntl;
$count = 0;
while (1) {
#sysopen(FH, "/scratch/logfile", O_RDWR|O_APPEND|O_CREAT|O_SYNC)
sysopen(FH, "/scratch/logfile", O_RDWR|O_APPEND|O_CREAT)
        or die "Couldn't open file $path : $!\n";
print FH "Log file line ", $count , " yadda  yadda  yadda  yadda  yadda  yadda 
yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda 
yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda 
yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda 
yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda 
yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda 
yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda 
yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda 
yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda 
yadda  yadda  yadda  yadda  yadda  yadda  yadda  yadda \n" ;
close (FH);
#print $count , "\n";
$count++;
}


------------------------------------------------------
Philip R. Auld, Ph.D.                  Technical Staff 
Egenera Corp.                        pauld@egenera.com
165 Forest St, Marlboro, MA 01752        (508)786-9444

Re: ReiserFS / 2.4.6 / Data Corruption

[Alan Cox]

> > Full data journalling will give you what you expect but at a performance hit
> > for many applications.
> 
> Do any of the other journalled filesystems for linux do this? If not, I
> guess I'll go back to ext2.

ext3 can do full data journalling, I dont know if reiserfs has an option for
it or not

Alan

Re: ReiserFS / 2.4.6 / Data Corruption

[bvermeul]

On Fri, 27 Jul 2001, Alan Cox wrote:

> > > Putting a sync just before the insmod when developing new drivers is a good
> > > idea btw
> >
> > I've been doing that most of the time. But I sometimes forget that.
> > But as I said, it's not something I expected from a journalled filesystem.
>
> You misunderstand journalling then

Yup, I guess I did.

> A journalling file system can offer different levels of guarantee. With
> metadata only journalling you don't take any real performance hit but your
> file system is always consistent on reboot (consistent as in fsck would pass
> it) but it makes no guarantee that data blocks got written.

I allways thought that it could/would roll back the changes that weren't
consistent. But I stand corrected. Thanks... :)

> Full data journalling will give you what you expect but at a performance hit
> for many applications.

Do any of the other journalled filesystems for linux do this? If not, I
guess I'll go back to ext2.

Bas Vermeulen

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

"God is more forgiving."
	-- Dave Aronson

Re: ReiserFS / 2.4.6 / Data Corruption

[Alan Cox]

> > Putting a sync just before the insmod when developing new drivers is a good
> > idea btw
> 
> I've been doing that most of the time. But I sometimes forget that.
> But as I said, it's not something I expected from a journalled filesystem.

You misunderstand journalling then

A journalling file system can offer different levels of guarantee. With 
metadata only journalling you don't take any real performance hit but your
file system is always consistent on reboot (consistent as in fsck would pass
it) but it makes no guarantee that data blocks got written.

Full data journalling will give you what you expect but at a performance hit
for many applications.

Alan

Re: ReiserFS / 2.4.6 / Data Corruption

[bvermeul]

On Fri, 27 Jul 2001, Alan Cox wrote:

> > > 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?
>
> Its certainly a good idea. But it sounds to me like he is describing the
> normal effect of metadata only logging.
>
> Putting a sync just before the insmod when developing new drivers is a good
> idea btw

I've been doing that most of the time. But I sometimes forget that.
But as I said, it's not something I expected from a journalled filesystem.

Regards,

Bas Vermeulen

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

"God is more forgiving."
	-- Dave Aronson

Re: ReiserFS / 2.4.6 / Data Corruption

[Alan Cox]

> > 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?

Its certainly a good idea. But it sounds to me like he is describing the
normal effect of metadata only logging. 

Putting a sync just before the insmod when developing new drivers is a good
idea btw