Bryan J. Smith wrote: >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. > > > > 1. You're ranting. 2. You're doing it in the wrong place. 3. If you turn your passions into action, rather than ranting, you might be pleasantly surprised by the results. Your opinions regarding the assorted filesystems really are irrelevant to this list, as are the technical details behind those reasons. It is not that nobody cares, but nobody here is prepared to do anything about it. You should offer assistance to the developers of XFS on Linux. If upstream support for XFS improves, Red Hat and/or the Fedora Foundation will be more inclined to support it. As Rahul and I have suggested, you are welcome to create an *objective* wiki page, describing the reasons behind the inclusion/exclusion of different filesystem types. Anything else is off-topic on this list, and is likely to be met only with hostility or frustration. -- Patrick "The N-Man" Barnes nman64@xxxxxxxxx www.n-man.com --
Attachment:
signature.asc
Description: OpenPGP digital signature
-- Fedora-marketing-list mailing list Fedora-marketing-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-marketing-list
