Message-ID: <3ADF0F19.B95F9EA2@ieee.org>
Date: Thu, 19 Apr 2001 12:15:22 -0400
From: "Bryan J. Smith" <b.j.smith@ieee.org>
Reply-To: b.j.smith@ieee.org, thebs@theseus.com
Organization: (personal/non-Theseus-related/liable)
MIME-Version: 1.0
To: Chip Salzenberg <chip@valinux.com>, Samuel Flory <sflory@valinux.com>
CC: linux-xfs@oss.sgi.com, nfs@lists.sourceforge.net
Subject: Re: VALinux and Ext3 -- Chip & Samuel's responses
References: <3ADD9BBD.DECCC102@ieee.org> <20010418150552.T7975@valinux.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-linux-xfs@oss.sgi.com
Precedence: bulk

Re: VALinux and Ext3 -- Chip & Samuel's responses

Chip Salzenberg wrote:
> Well, we aren't really "behind" ext3, any more than we're "behind" any
> other filesystem.  We certainly did choose to use ext3 in our NAS
> product.  But given that [1] NAS has to have rock-solid NFS service,
> [2] ext2 is the best-tested FS for NFS, and [3] ext3 is based on ext2,
> it seemed a natural choice.

I agree whole-heartedly.  I wouldn't be releasing a NAS device based
on the kernel 2.4 at this time anyway, let alone one with XFS.  I
just wanted to show some people that Ext3 *IS* "production quality."

In fact, I've been using Ext3 in v1 mode (full-data journaling)
since mid-2000 -- with your kernel's nonetheless (HJL's RPMs for
RedHat)!  Many other people have downloaded and used your 6.2.4
distro with Ext3.  Since ReiserFS has issues with kNFSd on kernel
2.2., it wasn't an option for my production UNIX network with NFS
everywhere (with 90% of our apps being UNIX-based).

Chip Salzenberg wrote:
> We aren't neophiles ... at least, our managers aren't ... so we don't
> deploy stuff just because it exists.  And if you check our kernel,
> you'll find that it's essentially based on SuSE's kernel, not Red
> Hat's.  We'll deploy whatever will serve our customers best.

I didn't know it was based on SuSE -- thanx for the tip!  As far as
XFS, I was curious as to if VA was waiting on the Ext3 port to 2.4,
evaluating XFS, or hoping the kNFSd patches for ReiserFS were
sufficient.

Samuel Flory wrote:
> The other real advantage for our customers is the fact that existing
> ext2 partition can easily be converted to and from ext2.

Yes, I've done that a couple of times before.  It's just a few
tune2fs changes (and making sure either the Ext3 journal was flushed
via a proper umount or mount/flush, or doing a regular Ext2 fsck).

Samuel Flory wrote:
> Right now there are at least 4 jfs under linux in various states
> of developement.

Yep.  If you are interested, I did a presentation for my local LUG
in March:
http://www.smithconcepts.com/files/presentations/ELUG_JFS_2001Mar05a.pdf

I know nothing of IBM's JFS (I was even wrong about the license in
my presentation, I thought it was IPL, when it is GPL), but someone
said its no where near production.  ReiserFS has traditional inode
compatibility issues (like with kNFSd), which leaves only Ext3 or
XFS for production UNIX networks/applications.

Again, I've been running Ext3 under kernel 2.2 for 9 months now --
on production servers and workstations (including my main NFS/SMB
server).  I love it!  For kernel 2.4 on workstations that need more
device support (yes, I'm using the USB and IDE backports to 2.2 c/o
your kernels -- but it's still not enough), I've had to go XFS in
the absence of Ext3 for kernel 2.4.  In fact, I'd prefer Ext3
because of its backward compatibility at this point in the game.

But it's obvious that XFS is the future of a production JFS for
Linux file servers -- at least over ReiserFS in many cases because
of its traditional inode layout (and seems to be more feature-rich
anyway).  At this point, I consider XFS my _only_ choice of a JFS on
kernel 2.4 workstations.  Although I will freely admit I *AM*
playing with ReiserFS for a kernel 2.4 version of SmoothWall with an
integrated Squid Cache Proxy (damn does ReiserFS fly on small files
like Squid's cache directory layout!).

Samuel Flory wrote:
> If we chose one before things stablize.  We might be left with the
> choice later on down the road of having to stick /w an inferior
> implementation, or telling customers. "You know how we told you to use
> Tobias' WizBang fs. We'll you should really be using Jake's Greased
> Weasel fs now.  Ohh yeah, and you'll have reformat those 2TB array."

Which was my original point.  By using Ext3, you can revert back to
Ext2, and retrieve the data under _any_ kernel.  This is important
for switching to a different JFS at some later date -- although
that's not to say Ext3 won't be around.  Again, I was just
interested in what VALinux's testing/plan was for the various JFS'
-- but understood you consider Ext3 to be "production ready" today
-- same as I.

-- TheBS

P.S.  Does the NAS product use Ext3 in v1 or v2 modes (i.e. full or
meta-data?).  I've had issues with the later, so I always stick with
the former (use "-o data=journal" with Ext3 v0.0.4+).

--
Bryan "TheBS" Smith          chat:thebs413 @AOL/MSN/Yahoo
Engineer      mailto:b.j.smith@ieee.org,thebs@theseus.com
*********************************************************
"Never apply a Star Trek solution to a Babylon 5 problem"
                                    -- Nicholas C. Weaver