Re: Linux 2.4 future

[jw schultz <jw@pegasys.ws>]

On Wed, Dec 03, 2003 at 05:47:43PM -0800, Mike Fedyk wrote:
> On Wed, Dec 03, 2003 at 05:24:20PM -0800, jw schultz wrote:
> > <OT>
> > As a datapoint i'm running ext2, reiserfs, JFS and XFS each
> > for different reasons.
> > 
> > 	ext2 -- boot (i'm stodgy) and 2kb blocks for archive CDs
> > 
> > 	reiserfs3 -- filesystems not exported nfs (no
> > 	historical version level that i can confirm whether
> > 	i have or not will namesys assert is reliable over
> > 	nfs)
> > 
> 
> Maybe you should just try it?  I've used reiserfs on an NFS/samba server,
> and it didn't give me trouble.

I did once.  Seemed fine for a while then it hit problems
(don't recall specifics) with some files.  Very painful
transitioning active filesystems.  Since then practically
every new version has claimed to have fixed NFS.  I'll wait
until the fix doesn't need to be fixed again for a few revs.

> 
> > 	jfs -- most nfs exported filesystems, decent
> > 	performance and solid but i don't use if for home
> > 	because in SuSE's 2.4.18 (i know it is ancient but
> > 	solid for me) jfs doesn't update mtime of
> > 	directories unless the block allocation changes
> > 	breaking maildir update detection.
> 
> This has been fixed in newer versions of JFS though, right?

Dunno,  I assume so.  It is a pretty obvious bug by the time
i had a server running JFS the kernel i was running was
already old.

If you are running JFS it is easy to test.  Just create a
directory with some files in it and rename or delete one so
the block count of the directory is unchanged and look at
the mtime.

> > 	xfs -- home (because of the jfs bug) Earlier tests
> > 	of xfs gave me horrible performance and i haven't
> > 	gotten around to testing since then.  If this is
> > 	fixed without tuning i might drop jfs.  Then again i
> > 	may drop xfs in the next upgrade if i change distros
> > 	and xfs isn't in-kernel.
> 
> What about ext3?  I tend to prefer ext3 since I know how it works more than
> the others, and it puts data integrity ahead of performance, which is the
> way things should be (TM).

I see too many reports of lost files and ext3 running in a
degraded state unnoticed to trust it.  The features list is
great but there are just too many bugfixes between kernel
versions in production and HEAD.  When i've XFS, reiserfs
and JFS to choose from the need for ext3 just isn't there at
this time.  The added confidence of data journalling on
systems that don't crash just doesn't outweigh doubts caused
by reports of silently lost files. (look further down the
other branch from the message to which this is a reply)

I appreciate the work that has gone into ext3 and have some
hopes that in time it may get past any real or imagined
deficiencies.  I suspect that the biggest value of ext3 at
this time is as a labratory for testing filesystem theory
and new features.


-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw@pegasys.ws

		Remember Cernan and Schmitt