From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-14) on finch.gentoo.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=5.0 tests=DMARC_MISSING, MAILING_LIST_MULTI,RDNS_DYNAMIC autolearn=unavailable autolearn_force=no version=4.0.0 Received: from brazil.sys.kcco.com (leg-66-247-92-2-CHI.sprinthome.com [66.247.92.2]) by chiba.3jane.net (Postfix) with ESMTP id 01363ABD7A for ; Tue, 14 May 2002 11:16:14 -0500 (CDT) Received: from brazil.sys.kcco.com (localhost [127.0.0.1]) by brazil.sys.kcco.com (Postfix) with ESMTP id 1B617C1F85; Tue, 14 May 2002 11:21:03 -0500 (CDT) Content-Type: text/plain; charset="iso-8859-1" From: Jean-Michel Smith To: gentoo-dev@gentoo.org, Mark Bainter Subject: Re: [gentoo-dev] reiserfs Date: Tue, 14 May 2002 11:21:02 -0500 X-Mailer: KMail [version 1.4] References: <23DFAA462CC6A64487613B0E242D9FF706EC65@mercury.phoenix-interactive.com> <200205141039.19317.jsmith@kcco.com> <20020514105242.N5849@firinn.org> In-Reply-To: <20020514105242.N5849@firinn.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200205141121.02234.jsmith@kcco.com> Sender: gentoo-dev-admin@gentoo.org Errors-To: gentoo-dev-admin@gentoo.org X-BeenThere: gentoo-dev@gentoo.org X-Mailman-Version: 2.0.6 Precedence: bulk Reply-To: gentoo-dev@gentoo.org List-Help: List-Post: List-Subscribe: , List-Id: Gentoo Linux developer list List-Unsubscribe: , List-Archive: X-Archives-Salt: 6e4cd732-bfb3-47f9-8d4a-918b81228578 X-Archives-Hash: 5fd452f2e0d40765593c90bd1191fc22 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 runni= ng > reiserfs with no problems before you think it's stable? I personally h= ave > been running reiserfs on my systems since before it was even merged int= o > 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=20 NOT shut down improperly, or suffered a kernel hang, or any other sort of= =20 disruption that one could reasonably expect would lead to filesystem=20 corruption. In all the years I've been using GNU/Linux (since 1993) I have never seen= this=20 on ext2. Nor have I seen it on XFS (which I have been using for over 3 y= ears=20 now on several production boxes). I have not seen it happen with JFS or=20 ext3, though admittedly I haven't used either of those two nearly as=20 extensively as I have ext2 and XFS. So, in answer to your first question, I require that a filesystem NOT=20 spontaneously lose or corrupt data, or mysteriously delete entire directo= ry=20 trees with no apparent cause. To date all of the filesystems I have trie= d=20 have met this rather modest standard, with the exception of Reiser, which= has=20 failed it dramatically. Now, if you shut down a buffered filesystem improperly then yes, you shou= ld=20 expect filesystem corruption to occur (though most of the time you will g= et=20 lucky and be fine). Even there, I've not had filesystem corruption probl= ems=20 with either XFS or JFS (though data can and does get lost/corrupted when = the=20 power is interrupted in this fashion). ext3 the verdict is still out on=20 (I've only been playing with it on one machine ... thus far no problems b= ut=20 more testing is required to be certain). I've got GNU/Linux systems running as routers that have uptimes measured = in=20 hundreds of days (one of them for 460 days last I checked), with never a=20 disruption or spontaneous filesystem going corrupt (they are using ext2).= =20 Every single reiserfs installation I had (6 or 7 IIRC) had corrupt=20 filesystems that were unrecoverable within 6 months ... despite having ne= ver=20 been improperly shut down or otherwise mistreated in a fashion that would= =20 lead one to expect, or accpet, such behavior. Based on this experience I do not consider Reiserfs at all safe to deploy= =2E =20 XFS is safe, as long as you're not aggressively hacking the kernel (it is= =20 intrusive, so mucking about with other kenel hacks can affect its=20 reliability. For this reason, if you're using XFS you should stick to st= ock=20 kernels to which only the XFS patch has been applied IMHO). JFS also app= ears=20 to be very safe. Ext2 is very safe, as long as you treat it properly (do= not=20 shutdown improperly, and keep on a UPS if there is a concern about power=20 reliability), or turn buffering off (this will slow it down, but make it = safe=20 even in error prone situations, such as working with unstable, experiment= al=20 kernels or a buggy X installatino). Ext3 appears to be ok, but I haven't= =20 used it enough to know that with certainty. I tend to treat my ext3=20 installation as an ext2 filesystem, so I haven't really put the journalli= ng=20 to a thorough test yet. Reiser comes nowhere near being as safe or stable as these alternatives (= with=20 the possible exception of ext3 which I need to do more testing with). Jean.