ReiserFS / 2.4.6 / Data Corruption
Hans Reiser
Hans
Steve Kieu wrote:
>
> --- Erik Mouw <J.A.K...@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...@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 majo...@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 majo...@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 majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Erik Mouw
> --- Erik Mouw <J.A.K...@ITS.TUDelft.NL> wrote: > On
>
> 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.
bver...@devel.blackstar.nl
> 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
Hans Reiser
Do you think it is reasonable to ask that a filesystem be designed to work well with bad drivers?
Alan Cox
> > 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).
> >
> 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
bver...@devel.blackstar.nl
> > > 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
-
bver...@devel.blackstar.nl
> bver...@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.
Alan Cox
> > 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
Alan Cox
> > 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
bver...@devel.blackstar.nl
> > > 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
-
Alan Cox
> 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
Hans Reiser
>
> > > 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?
>
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.)
Philip R. Auld
>
> 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. pa...@egenera.com
165 Forest St, Marlboro, MA 01752 (508)786-9444
Hans Reiser
> 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
Chris Wedgwood
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
Alan Cox
> 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
bver...@devel.blackstar.nl
> 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
-
Jordan
>
> 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.
>
> (and works really well if you are willing to take the performance hit).
>
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majo...@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
Hans Reiser
>
> 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
Hans Reiser
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
bver...@devel.blackstar.nl wrote:
>
> On Fri, 27 Jul 2001, Hans Reiser wrote:
>
> > bver...@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
>
Chris Wedgwood
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
Cress, Andrew R
On Fri, Jul 27, 2001 at 06:55:09PM +0400, Hans Reiser wrote:
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
Hans Reiser
>
> 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.
>
> 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
Hans Reiser
>
> > 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.
>
> 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.
>
> > they run fsck or what?
>
> 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
Philip R. Auld
>
> "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).
>
> 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. pa...@egenera.com
165 Forest St, Marlboro, MA 01752 (508)786-9444
Hans Reiser
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
Henning P. Schmiedehausen
>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 h...@intermeta.de
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 in...@intermeta.de
D-91054 Buckenhof Fax.: 09131 / 50654-20
Alan Cox
> > 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
Hans Reiser
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.
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).
Andrew Morton
>
> 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
> 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);
Hans Reiser
> 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
Alan Cox
> 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
Hans Reiser
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
Ville Herva
>
> 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 --
Eric W. Biederman
> 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
Andrew Morton
>
> 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.
-
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
Alan Cox
> 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.
Christoph Rohland
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
Ville Herva
> > 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 --
Hans Reiser
>
> 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 majo...@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
Hans Reiser
>
> 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
Dustin Byford
> 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
bver...@devel.blackstar.nl
> Hans Reiser <rei...@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
-
Jussi Laako
>
> 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
Hans Reiser
> 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
Hans Reiser
>
> On 27 Jul 2001, Eric W. Biederman wrote:
>
> > Hans Reiser <rei...@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.
>
> I don't like using reiserfs on my development system. My files get
> 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
we'd like your help in reproducing it.
Marc A. Lehmann
> 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 +--
--==---/ / _ \/ // /\ \/ / p...@goof.com |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
Alan Cox
> 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.
Hans Reiser
> > 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
Marc A. Lehmann
> > 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 +--
--==---/ / _ \/ // /\ \/ / p...@goof.com |e|
-=====/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
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
Hans Reiser
>
> > 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?
>
> 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 majo...@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
Alan Cox
> 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.
bver...@devel.blackstar.nl
> 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
-
bver...@devel.blackstar.nl
> bver...@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.
Hans Reiser
>
> > 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.
Hans
Hans Reiser
>
> > 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.
>
>
> --
> "God, root, what is difference?"
> -- Pitr, User Friendly
>
> "God is more forgiving."
> -- Dave Aronson
hans
Chris Mason
On Saturday, July 28, 2001 11:36:33 AM +0400 Hans Reiser <rei...@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
bver...@devel.blackstar.nl
> 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
-
Alan Cox
> 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
Henning P. Schmiedehausen
> 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 h...@intermeta.de
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 in...@intermeta.de
D-91054 Buckenhof Fax.: 09131 / 50654-20
Hans Reiser
>
> 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?
> >
>
> 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
Marcus Meissner
> 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
Christoph Hellwig
In article <0107290145...@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.