From: Joshua Baker-LePain jlb17@duke.edu
The canonical reasons I've heard are 1) they don't want to spend the money/time/resources to acquire enough XFS expertise to support it at the Enterprise level
I could think of 2 guys they could easily snatch away from SGI that could bring such experience -- pretty much the 2 behind much of the VFS in kernel 2.6 anyway (so great resources regardless).
and 2) besides, as of RHEL4 (they claim), XFS doesn't provide anything ext3 already provides, so why bother.
Feature-wise, probably not. The VFS in 2.6 brings a lot of former XFS-only features to _all_ filesystems. But I still see serious size limitations as well as scalability to Ext3 versus XFS.
Yes, I've pointed out on official Red Hat mailing lists that 2 is false due (at least) to the issue of backing up ACLs (use star they say -- no thanks,
Well, Red Hat has shipped Jorg's "star" in RHL8 on-ward to address this.
say I), but I got no response to that. And I've got benchmarks showing XFS pretty handily beating ext3 on nice new hardware, but I don't have much faith that would get any response either.
To me, I really could care less about benchmarks except when real performance issues arise.
All throughout 2.4, every other filesystem -- Ext3, JFS (from OS/2**), ReiserFS, etc... required hack after hack after hack. XFS, with its "core" additions to kernel 2.4 provided _everything_ standard from day 1 -- Quotas, POSIX EA/ACLs, etc... It was ported directly from Irix, and was _entirely_ GPL -- which you'd figure that's something Red Hat likes.
The only bug that it ever ran into, which resulted in XFS 1.1, was something that bit me on 2 /var filesystems. Otherwise XFS, like Ext3 but _unlike_ JFS or ReiserFS, benefits from being the _exact_ _same_ organization for 10+ years. Which means not only is its on-line operation well-trusted, but it's off-line fsck/repair as well (something that plagues ReiserFS heavily due to design focus).
Because I could care less how a filesystem works when it works. I want to know what happens when its inconsistent, and a journal reply won't solve the problem. I trust e2fsck and xfs_repair.
-- Bryan J. Smith mailto:b.j.smith@ieee.org
On Tue, Jun 14, 2005 at 03:10:50PM -0500, Bryan J. Smith b.j.smith@ieee.org wrote:
The canonical reasons I've heard are 1) they don't want to spend the money/time/resources to acquire enough XFS expertise to support it at the Enterprise level
I could think of 2 guys they could easily snatch away from SGI that could bring such experience -- pretty much the 2 behind much of the VFS in kernel 2.6 anyway (so great resources regardless).
The main argument I can see is "clean upgrade path". XFS doesn't offer anything hugely compelling over ext3 -- which is, after all, very flexible and extensible. And Red Hat already *has* Stephen Tweedie.
Feature-wise, probably not. The VFS in 2.6 brings a lot of former XFS-only features to _all_ filesystems. But I still see serious size limitations as well as scalability to Ext3 versus XFS.
Serious in some cases; not in the general case. Given the above, there has to be something *widespread* that ext3 just *can't* do.
On Tue, 14 Jun 2005 at 3:10pm, Bryan J. Smith b.j.smith@ieee.org wrote
From: Joshua Baker-LePain jlb17@duke.edu
Yes, I've pointed out on official Red Hat mailing lists that 2 is false due (at least) to the issue of backing up ACLs (use star they say -- no thanks,
Well, Red Hat has shipped Jorg's "star" in RHL8 on-ward to address this.
According to the version number on RHEL4's version of star (yes, I know you can't always go by that) and the datestamps at ftp://ftp.berlios.de/pub/star/alpha/, RHEL4's star is from 9/13/2003(!!). The main patching I see in the .spec file is selinux related (as one would expect). Thus, according to the revision history at the ftp site above, RHEL4's star has rudimentary incremental backup support and *no* incremental restore support. Not exactly enterprise software, IMHO.
-
Bryan J. Smith <b.j.smith＠ieee.org> -
Joshua Baker-LePain -
Matthew Miller