All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Fedyk <mfedyk@matchmail.com>
To: Bernd Schubert <bernd-schubert@web.de>
Cc: reiserfs-list@namesys.com, Chris Mason <mason@suse.com>,
	Andrew Morton <akpm@osdl.org>
Subject: Re: reiserfs logging patches udpated
Date: Wed, 24 Mar 2004 19:56:23 -0800	[thread overview]
Message-ID: <40625867.4060800@matchmail.com> (raw)
In-Reply-To: <200403250147.54246.bernd-schubert@web.de>

Bernd Schubert wrote:
> However, besides of the proper discussion about the ide problem, there was a 
> 'sub' thread with about 50 messages about the instability of reiserfs!!!

I wouldn't be surprised, you get this in the debian lists also.

But, the thing is...  I wouldn't trust my data to any filesystem without 
a data=ordered mode.  I've used reiserfs on a few systems and it does 
have a speed increase, but the journaling is like ext2 -- it just 
journals what it has done, there is no ordering performed *at all* (that 
is until Suse's data=X journaling patches for reiser3).

Adding the fact that reiserfsck3 is just recently getting out of beta 
level quality (crashes, livelocks & etc during fsck and etc were common 
until the last few months)

And after having the difference of a block level journal (ext3), instead 
of a "virtual" journal(reiserfs, jfs, xfs) explained to me (check the 
ext3-users archives...) -- and how it can save your ass when there are 
hardware problems.  I was convinced and switched everything back to ext3.

The basic idea of virtual vs block journals, is that instead of using a 
few bytes to describe what you're changing in (for instance) the inode 
table (or equivalent), ext3 copies entire inode table block (usually 
1-4k depending on block size) into the journal.

Where this can save your ass is where some power or other hardware 
problem caused your drive to overwrite one of your inode tables (or 
bitmaps or...).  Well, some of your data will be corrupted, but if that 
inode table was written to relatively recently, it'll be restored from 
the journal during recovery.

Yes, I saw speed increases with reiserfs3, but I *will not* use it with 
critical systems that don't have a power backup and raid system (since 
reiserfs3 really sucks at handling bad blocks).

If I get the time, I'll help test the reiser3 patches in -mm.  Thank you 
  Chris for working on this direly needed patch, I'll feel comfortable 
with my systems running reiser3 once they're running with this patch.

Mike

  parent reply	other threads:[~2004-03-25  3:56 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-24 17:29 reiserfs logging patches udpated Chris Mason
2004-03-24 19:08 ` Christian Mayrhuber
2004-03-24 19:43 ` Lamont R. Peterson
2004-03-24 19:49 ` Hubert Chan
2004-03-24 20:06   ` Chris Mason
2004-03-24 22:18 ` Andrew Morton
2004-03-24 22:26   ` Chris Mason
2004-03-24 22:35     ` Andrew Morton
2004-03-24 22:46       ` Chris Mason
2004-03-24 22:59         ` Andrew Morton
2004-03-24 23:03           ` Chris Mason
2004-03-25  0:47         ` Bernd Schubert
2004-03-25  1:00           ` Chris Mason
2004-03-25  1:14             ` Dieter Nützel
2004-03-25 18:11             ` Bernd Schubert
2004-03-25 18:19               ` Chris Mason
2004-03-25 18:59                 ` Bernd Schubert
2004-03-25 19:07                   ` Chris Mason
2004-03-25 19:22                 ` Matthias Andree
2004-03-25  3:56           ` Mike Fedyk [this message]
2004-03-25 14:14             ` Chris Mason
2004-03-25 20:41               ` Mike Fedyk
2004-03-25 20:50                 ` Chris Mason
2004-03-29 13:10                   ` Hans Reiser
2004-03-29 18:49                     ` Mike Fedyk
2004-03-30 17:16                       ` Nikita Danilov
2004-03-30 19:06                         ` Mike Fedyk
2004-03-25 16:51             ` Dieter Nützel
2004-03-25 19:02           ` Matthias Andree

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=40625867.4060800@matchmail.com \
    --to=mfedyk@matchmail.com \
    --cc=akpm@osdl.org \
    --cc=bernd-schubert@web.de \
    --cc=mason@suse.com \
    --cc=reiserfs-list@namesys.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.