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 filesystems. 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 mid-'90s. 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@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
