public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Jean-Michel Smith <jsmith@kcco.com>
To: gentoo-dev@gentoo.org, Mark Bainter <mark-gt@cymry.org>
Subject: Re: [gentoo-dev] reiserfs
Date: Tue, 14 May 2002 11:21:02 -0500	[thread overview]
Message-ID: <200205141121.02234.jsmith@kcco.com> (raw)
In-Reply-To: <20020514105242.N5849@firinn.org>

On Tuesday 14 May 2002 10:52 am, Mark Bainter wrote:
> Jean-Michel Smith [jsmith@kcco.com] wrote:
> > Reiserfs is NOT ready for production use, and the gentoo FAQ is both wise
> > and friendly for pointing that out and guiding people away from that
> > particular folly.
>
> I just can't agree.  What exactly is your required time frame for running
> reiserfs with no problems before you think it's stable?  I personally have
> been running reiserfs on my systems since before it was even merged into
> the mainline kernel.  I work the hell out of my systems and I've never had
> a problem.

First, I've had resier lose data on systems that were running fine, i.e. were 
NOT shut down improperly, or suffered a kernel hang, or any other sort of 
disruption that one could reasonably expect would lead to filesystem 
corruption.

In all the years I've been using GNU/Linux (since 1993) I have never seen this 
on ext2.  Nor have I seen it on XFS (which I have been using for over 3 years 
now on several production boxes).  I have not seen it happen with JFS or 
ext3, though admittedly I haven't used either of those two nearly as 
extensively as I have ext2 and XFS.

So, in answer to your first question, I require that a filesystem NOT 
spontaneously lose or corrupt data, or mysteriously delete entire directory 
trees with no apparent cause.  To date all of the filesystems I have tried 
have met this rather modest standard, with the exception of Reiser, which has 
failed it dramatically.

Now, if you shut down a buffered filesystem improperly then yes, you should 
expect filesystem corruption to occur (though most of the time you will get 
lucky and be fine).  Even there, I've not had filesystem corruption problems 
with either XFS or JFS (though data can and does get lost/corrupted when the 
power is interrupted in this fashion).  ext3 the verdict is still out on 
(I've only been playing with it on one machine ... thus far no problems but 
more testing is required to be certain).

I've got GNU/Linux systems running as routers that have uptimes measured in 
hundreds of days (one of them for 460 days last I checked), with never a 
disruption or spontaneous filesystem going corrupt (they are using ext2).  
Every single reiserfs installation I had (6 or 7 IIRC) had corrupt 
filesystems that were unrecoverable within 6 months ... despite having never 
been improperly shut down or otherwise mistreated in a fashion that would 
lead one to expect, or accpet, such behavior.

Based on this experience I do not consider Reiserfs at all safe to deploy.  
XFS is safe, as long as you're not aggressively hacking the kernel (it is 
intrusive, so mucking about with other kenel hacks can affect its 
reliability.  For this reason, if you're using XFS you should stick to stock 
kernels to which only the XFS patch has been applied IMHO).  JFS also appears 
to be very safe.  Ext2 is very safe, as long as you treat it properly (do not 
shutdown improperly, and keep on a UPS if there is a concern about power 
reliability), or turn buffering off (this will slow it down, but make it safe 
even in error prone situations, such as working with unstable, experimental 
kernels or a buggy X installatino).  Ext3 appears to be ok, but I haven't 
used it enough to know that with certainty.  I tend to treat my ext3 
installation as an ext2 filesystem, so I haven't really put the journalling 
to a thorough test yet.

Reiser comes nowhere near being as safe or stable as these alternatives (with 
the possible exception of ext3 which I need to do more testing with).

Jean.


  reply	other threads:[~2002-05-14 16:16 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-05-14 14:56 [gentoo-dev] reiserfs Sean Mitchell
2002-05-14 15:07 ` Alexander Gretencord
2002-05-14 15:39   ` Jean-Michel Smith
2002-05-14 15:52     ` Mark Bainter
2002-05-14 16:21       ` Jean-Michel Smith [this message]
2002-05-14 16:30         ` Ben Lutgens
2002-05-14 17:07     ` Alexander Gretencord
2002-05-14 17:22       ` Per Wigren
2002-05-14 18:50         ` Matthew Kennedy
2002-05-14 19:09           ` Jean-Michel Smith
2002-05-14 17:49       ` Mark Bainter
2002-05-14 18:17         ` Alexander Gretencord
2002-05-14 18:32           ` Mark Bainter
2002-05-14 19:03             ` Alexander Gretencord
2002-05-14 20:39         ` Mikko Moilanen
2002-05-14 22:44         ` Bill Kenworthy
2002-05-15  0:10           ` Jean-Michel Smith
2002-05-15  0:39             ` Spider
2002-05-15  0:57               ` Jean-Michel Smith
2002-05-14 21:29       ` Spider
  -- strict thread matches above, loose matches on Subject: below --
2002-05-14 15:39 Sean Mitchell
2002-05-14 14:44 Brady Wied
2002-05-14 21:17 ` Spider
2002-05-15  8:20   ` Alexander Gretencord

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=200205141121.02234.jsmith@kcco.com \
    --to=jsmith@kcco.com \
    --cc=gentoo-dev@gentoo.org \
    --cc=mark-gt@cymry.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox