For this weeks meeting agenda...

[Patrick Barnes]

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
>>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.
>
>
>  
>
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

www.n-man.com
-- 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: OpenPGP digital signature
Url : http://lists.fedoraproject.org/pipermail/marketing/attachments/20050911/7117c61c/attachment.bin