On 28 Mar 2003, Michael Wardle wrote: > On Wed, 2003-03-26 at 03:29, Ubaidul Khan wrote: > > Does anyone know if Redhat 9.0 will provide support of XFS (sgi's high > > performance file system)? I heard some talk of the new kernel (2.4.21) > > supporting XFS. > > I don't see any mention of XFS in the ChangeLog for Linux 2.4.21. > http://www.kernel.org/pub/linux/kernel/v2.4/testing/patch-2.4.21.log > > When last I read about this issue, it seemed that XFS support would only > be merged in to the official kernel for Linux 2.6 and later, and Red Hat > didn't want to apply the patches to Linux 2.4. I would conclude that > we'll see XFS in the first Red Hat release to use Linux 2.6 by default, > perhaps Red Hat 9.1 or 10, depending on what the next release is called. > > You can get a CD image of an SGI-customized version of Red Hat 8 that > includes XFS support from here: > ftp://oss.sgi.com/projects/xfs/download/Release-1.2/installer/
Depends on how you define as "see" in terms of how you expect the availablity to be provided. Red Hat seems to be very conservative when it comes to file system support. Also, the fact that ext3 seems to be their own in-house salid dressing seems to make the bias in continuing to promote it. Based on what I have seen in the beta releases, Anaconda still does not list reiserfs as an option during installation. The fact that the support is included in the kernel and the user-space utilities are provided seem to be an after-thought. Like other secondary offerings in the standard OS (CUPS, postfix, etc), it may be weeks after a know bug exists before they get around to releasing a kernel update or updated reiserfs util package. It is clear they don't want to provide support to alternatives when you compare this with the fact that new kernels or other packages (bugs with ext3, lpd, sendmail, etc) will come out days after a know bug. Even if SGI XFS or IBM JFS is provided in RH 9.1 or RH X kernel (along with supporting user-space utils), it is unlikely that RH trend will change and they will continue blowing off supporting the users of these alternatives. Unless your interested in tracking bugzilla and RawHide, I would avoid alternatives when expecting support from RH. What gets provided when you run "up2date" against RH's own RHN servers seems to be controlled by politics rather than technical. What I find the most disappointing is how much Red Hat has gone out of their way to avoid devfs. While it is debatable if this 2.4 kernel feature is worth while in a hard drive installed OS, it has become clear that it has it's advantages for rescue diskettes. Yet, work-arounds for detection and creation of devices still exist as part of Anaconda when booting in either install or rescue mode. There are several cases where devfs provides a more complette set of device nodes that Anaconda does. This can make a huge difference in the complexity of your rescue procedures. For example, restoring a file from tape may be an easier task with devfs but Anaconda seems to lack creating the approbate device files for accessing tape drive. Hence, an explaination of how to use mknod becomes part of any documentation on how to restore a file from tape while booting a RH CD in rescue mode. It much like RH's attitude towards ext3 over reiserfs, it seem RH doesn't care for the fact that devfs wasn't invented at RH but the Anaconda device node creator work-around was. "Not invented here" attitude can carry over to both XFS and JFS as well. -- redhat-list mailing list unsubscribe mailto:[EMAIL PROTECTED] https://listman.redhat.com/mailman/listinfo/redhat-list
