From owner-freebsd-current@FreeBSD.ORG Tue Oct 19 19:20:00 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 13F3F16A4CE for ; Tue, 19 Oct 2004 19:20:00 +0000 (GMT) Received: from mail.freebsd.org.cn (dns3.freebsd.org.cn [61.129.66.75]) by mx1.FreeBSD.org (Postfix) with SMTP id B70FE43D46 for ; Tue, 19 Oct 2004 19:19:58 +0000 (GMT) (envelope-from delphij@frontfree.net) Received: (qmail 82494 invoked by uid 0); 19 Oct 2004 19:15:08 -0000 Received: from unknown (HELO beastie.frontfree.net) (219.239.98.7) by mail.freebsd.org.cn with SMTP; 19 Oct 2004 19:15:08 -0000 Received: from localhost (localhost.frontfree.net [127.0.0.1]) by beastie.frontfree.net (Postfix) with ESMTP id 990D01318C8; Wed, 20 Oct 2004 03:19:52 +0800 (CST) Received: from beastie.frontfree.net ([127.0.0.1]) by localhost (beastie.frontfree.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03995-02; Wed, 20 Oct 2004 03:19:42 +0800 (CST) Received: by beastie.frontfree.net (Postfix, from userid 1001) id 298141318C1; Wed, 20 Oct 2004 03:19:41 +0800 (CST) Date: Wed, 20 Oct 2004 03:19:41 +0800 From: Xin LI To: Kalev Lember Message-ID: <20041019191941.GB1376@frontfree.net> References: <417538B9.7070001@club-internet.fr> <41755FAF.8080300@colleduc.ee> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="kfjH4zxOES6UT95V" Content-Disposition: inline In-Reply-To: <41755FAF.8080300@colleduc.ee> User-Agent: Mutt/1.4.2.1i X-GPG-key-ID/Fingerprint: 0xCAEEB8C0 / 43B8 B703 B8DD 0231 B333 DC28 39FB 93A0 CAEE B8C0 X-GPG-Public-Key: http://www.delphij.net/delphij.asc X-Operating-System: FreeBSD beastie.frontfree.net 5.3-delphij FreeBSD 5.3-delphij #4: Mon Sep 13 12:44:05 CST 2004 delphij@beastie.frontfree.net:/usr/obj/usr/src/sys/BEASTIE i386 X-URL: http://www.delphij.net X-By: delphij@beastie.frontfree.net X-Location: Beijing, China X-Virus-Scanned: by amavisd-new at frontfree.net cc: Jean-S?bastien P?dron cc: freebsd-current@freebsd.org Subject: Re: Read-only ReiserFS support for FreeBSD 5.x X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Oct 2004 19:20:00 -0000 --kfjH4zxOES6UT95V Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 19, 2004 at 09:40:47PM +0300, Kalev Lember wrote: > One of the things I have missed in FreeBSD is a good journaling=20 > filesystem. This is one of the places where Linux beats BSD: Linux=20 > supports far more filesystems that the BSDs do. =46rom my view, journaling is not necessarily to be superior than the SoftUpdates in FreeBSD, however, having journaling filesystem support will make it possible for us to actually *compare* them and improve our SoftUpdates implementation. If you have found that some filesystems outperform FreeBSD's, it might be because some other factors, and some of these can be changed by tuning up the file system, while some others lies on things other than journaling techniques. > Writing a journaling filesystem from scratch is not a trivial thing to=20 > do, however. Maybe we should consider using ReiserFS or some other=20 > journaling one as FreeBSD's primary filesystem now that the 6-current is= =20 > branched? I personally prefer SoftUpdates over Journalling because it guarantees that everything written on disk is consistent while Journalling does not (you'd say that it have transaction log and hence can rollback to a consistent state, however in most journalling implementations this is not done in a safe way so the reliability is in doubt). To get journalling work in a correct way you will need some non-violatile memory or UPS so the system can guarantee its writes to the transaction log area is done correctly. ReiserFS, however, *does* provide better performance when dealing with zill= ions of small files. I don't want to debate whether a well-designed system shou= ld actually utilize this, but I believe it would be beneficial to bring some different ideas we can take as reference :-) > One of the issues with ReiserFS is the licence of course. Yes for sure, and with this in concern it would not be possible for us to make it a part of kernel before someone actually re-write it from scratch. My intention is, however, to write a new (or to improve our existing) filesystem which is optimized for large files (e.g. databases), while providing "fairly good" performance when dealing with many small files. Cheers, --=20 Xin LI http://www.delphij.net/ See complete headers for GPG key and other information. --kfjH4zxOES6UT95V Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBdWjN/cVsHxFZiIoRAob6AJ4/nHgN1VpViWQtxiPW3jbQauXv1QCeKK2y p/arwu0182naTpe8Q9/ozxg= =TDC8 -----END PGP SIGNATURE----- --kfjH4zxOES6UT95V--