For this weeks meeting agenda...
nman64 at n-man.com
Sun Sep 11 20:53:26 UTC 2005
Bryan J. Smith wrote:
>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
>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
Suggestion: Why don't you go ahead and write a wiki page about the
assorted filesystems, their strengths and weaknesses, and why some
aren't currently in Fedora. You could create the page at
http://fedoraproject.org/wiki/FAQ/FileSystems and let me know when it is
ready for review. Once we have a good version in place, we can write in
just a small statement on the FedoraMyths page and direct the curious to
the new page. If you would like to follow the progress of filesystem
support and keep that page a living document, that would be great.
We'll also create a link to the new page directly off of the FAQ.
Patrick "The N-Man" Barnes
nman64 at n-man.com
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/marketing/attachments/20050911/7117c61c/attachment.bin
More information about the marketing