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@xxxxxxxx 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 -- Fedora-marketing-list mailing list Fedora-marketing-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-marketing-list
