[Date Prev][Date Next] [Thread Prev][Thread Next]
Re: For this weeks meeting agenda...
- From: "Bryan J. Smith" <b j smith ieee org>
- To: Discussions on expanding the Fedora user base <fedora-marketing-list redhat com>
- Subject: Re: For this weeks meeting agenda...
- Date: Sun, 11 Sep 2005 18:59:01 -0500
On Mon, 2005-09-12 at 04:13 +0530, Rahul Sundaram wrote:
> Never is a long time. Ext3 is under active development and will continue
> to get more enhancements .
Let me be the _first_ to thank Red Hat and Tweedie for the Ext3
filesystem. I trust it implicitly. It started saving my bacon in early
2000, and I have trusted it ever since. It was a much needed,
evolutionary filesystem from _trusted_ Ext2 which has not changed since
the mid-'90s. There's nothing like knowing you can always do a full
Ext2 fsck -- that's something I trust.
*BUT* I have 2 standing rules on my Ext3 deployments:
1. No Ext3 filesystem is ever larger than 1TB. I try to keep them
100GB or smaller. I still use Ext3 for system volumes, and I would
_never_ use another filesystem for /, /tmp, /var and several other
2. Avoid using Extended Attributes (EAs) on Ext3 for data filesystems,
except for SELinux. This is more of a backup consideration than
anything else. There is no "reliable" way to backup/restore EAs from
Ext3. Sorry, although I personally like Jorg's work, star is not what I
consider "enterprise quality."
Again, Ext3 will _continue_ to be a _good_ filesystem for Red Hat and
its integrators like myself. But I can_not_ entrust it as a solution
for multi-TB filesystems. Unfortunately, there's not much I can in
Linux, and that's the problem -- one Red Hat should help solve.
XFS is a no-brainer.
XFS' structure was designed for 64-bit, with extents, with delayed
writes, with EAs and other meta-data in the inodes, with a _full_suite_
of user-space tools from xfsdump to xfs_fsr (defragmentor) to the off-
line xfs_repair tool.
KEY POINT: This structure has _not_ changed since 1995.
Everything has been built around that structure since 1995. There are
no new "hacks" to "extend" the filesystem's design. It was not left
"incomplete." And XFS was a _direct_port_ from Irix to Linux, bringing
a _lot_ of capability to the kernel itself.
That included POSIX EA support from day 1, _official_ quota support even
_before_ Ext3, excellent kernel NFS support in the SGI XFS releases for
kernel 2.4 (although this is no longer the case) and many other details.
That is what I trusted from 2001-2004 -- especially the XFS 1.2 release
for Red Hat Linux 7.3 and 1.3.1 release for Red Hat Linux 9.
Unfortunately, there is _no_ other XFS release I can trust. It's not
the filesystem itself, it's the _lack_ of consideration on several
levels. XFS and SGI could really, really, _really_ use Red Hat's
assistance on developing XFS as a "standard" filesystem for 2.6 kernel
distributions. It's not that XFS is "experimental," it's just the
changes that have occurred in the kernel since the filesystem first came
over, and was extremely mission critical.
Including Red Hat changes like 4KiB stacks -- which I _do_ believe is a
good idea. In fact, I have been extremely complementary and supportive
of Red Hat's decision making versus SuSE, Debian and other
distributions. 9 times out of 10, Red Hat makes the best choice time
and time again. Ext3 was one of them. But Ext3 cannot continue to be
extended and still leverage its trusted structure that was _not_
designed for the scale and features that enterprises now need.
The problem is that everytime I bring this up, people treat me like I'm
some ReiserFS enthusiast who has never run large-scale NFS/SMB servers,
or a JFS advocate who doesn't know it's history on Linux. I _do_ use
Ext3 and I will _continue_ to deploy Ext3 for many filesystems. But
Ext3 is not "cutting it" for some large data filesystems, and it will
never offer what XFS has -- and more importantly -- has had since the
ReiserFS and JFS are basically "no way" on Red Hat, with Red Hat's
services focus, and I explain this to people regularly. Even SuSE
developers admit what ReiserFS cannot support, and most understand why
Red Hat does not support it. But XFS quite different in its
compatibility, and it is only because of kernel changes and lack of
distro support why issues are now occurring.
> If you want to send in customer feedback using the appropriate support
> channels would be a better idea. If you do believe that the page can
> highlight things in a better way that is invasive, make a alternative
> wiki page as a draft and point that to this list for dicussions
I will. Until then, I invite people to read my blog.
I'm an Ext3 system integrator. The problem is that the lack of XFS as a
complement to Ext3 is causing me to deploy Solaris/Opteron instead of
Linux/Opteron for LAN servers now. Again, I'm not so pundit with little
experience deploying mission critical LAN file servers claiming superior
performance out of ReiserFS, or JFS advocate who is oblivious to the
origins of Linux's JFS which has caused it's support issues.
I really don't prefer Sun. But because of Red Hat's stance, I've gone
from moving from Solaris to Linux only to be moving back towards Solaris
for some services. Linux is great for web servers, database servers
(using "raw" volumes for Oracle, or smaller MySQL/PostgresSQL
filesystems), grid computing and other areas. But for large file
servers, the lack of a turnkey Linux distro with XFS (since the older
SGI releases), has pushed me back to UNIX, and Solaris is where it's at
for LAN fileservers -- especially on Opteron.
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]