[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: For this weeks meeting agenda...



On Sun, 2005-09-11 at 16:12 +0100, Stuart Ellis wrote:
> As has already been said, it may not need much detail. The important
> points are probably that ReiserFS doesn't yet support key features x, y
> and z,

Correct, that _needs_ to be in there.  The problem with so many ReiserFS
advocates is that they've _never_ used it for a production NFS server,
or never used EAs.  And there are recovery issues with the off-line
tools being "out-of-sync" with changes in the filesystem (something that
doesn't happen with Ext3 or XFS which have remained unchanged
structurally for 10+ years).

> and XFS isn't suited or reliable for standard setups.

XFS is _very_reliable_, but _only_ in the official SGI releases.  I've
found that XFS in the stock kernel is _not_, and most 3rd party rebuilds
are incomplete and buggy.

I wish Red Hat would support XFS.  It has all the interface/
compatibility, features of Ext3, plus a number more that enterprises
need.  But until Red Hat takes the time to build and test a "complete"
XFS -- I can't trust the stock kernel builds or 3rd parties.

> I tagged that myth on after an IRC discussion about unreasonable user
> requests - people semi-regularly claim that Fedora should
> support/default to ReiserFS (as SUSE does, I think) because it's
> supposedly faster or cleverer or whatever,

ReiserFS is innovative.  And it utterly _breaks_ standard kernel
interfaces and compatibility as a result.  Even SuSE developers have
told me _not_ to use it for my needs, because their hacks for many
things (from NFS to EAs) are suspect.

> and that XFS is l33t, so it should be a standard installation option.

Actually, Red Hat needs to realize that Ext3 has scalability issues (I
don't like it above 100GB and I do _not_ trust it above 1TB), and
_lacks_ a lot of user-space features of XFS like xfsdump, xfs_fsr,
etc..., let alone EAs and other meta-data is stored directly in the
inode (which xfsdump then retains).

I still have quite a number of Red Hat Linux 7.3 systems in heavy, heavy
production with SGI's official XFS 1.2.x release, and one major Red Hat
Linux 9 system with SGI's official XFS 1.3.1 release.  But that's the
key issue, they are the _only_ official SGI releases for any distro.

I've tried to integrate SGI's kernel builds from CVS into Red Hat
distros to little avail.  And as I mentioned, the stock kernel releases
are incomplete -- especially the 2.4 backport that is now in the stock
2.4 kernel.  I would _never_ run it, and the stock 2.6 kernel continues
to be suspect.

Which means until Red Hat pro-actively develops and tests XFS in newer
kernel 2.6 Fedora Core releases, I can't trust XFS either.

WHICH MEANS (AND I HOPE RED HAT IS LISTENING ;-), when I need a large,
scalable, high-performance NFS/LAN file server for my Fortune 100
clients -- I deploy Solaris/Opteron now.  Ext3 is _not_ cut it, and it
_never_ will.  I have to agree 100% with Schwartz's comments -- Red Hat
is _ignoring_ a significant segment of the enterprise LAN server market.

I still long for the day of the Ext3 + XFS combination Red Hat
distribution.  Ext3 is better for system and smaller data volumes, XFS
is better for larger (especially large file) volumes.  But that died
once SGI stopped releasing official releases -- the last being 1.3.1 for
Red Hat Linux 9.

It's not about "l33t" -- there are serious enterprise features missing
in Ext3.


-- 
Bryan J. Smith     b j smith ieee org     http://thebs413.blogspot.com
----------------------------------------------------------------------
The best things in life are NOT free - which is why life is easiest if
you save all the bills until you can share them with the perfect woman


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]