Les Mikesell wrote:

Any chance of a really-really-unsupported kernel as in the latest fedora 2.6.13.x rebuilt for Centos? I'm beginning to think that fireware disk support might finally be reliable there. Or maybe a backport of whatever has been done to the ohci1394, ieee1394, and sbp2 modules?

You should be able to just grab the sources from download.fedora.redhat.com and rebuild ? you might need to update some other core pkgs to satisfy depends tho.

- K

Karanbir Singh enlightened us:

You should be able to just grab the sources from download.fedora.redhat.com and rebuild ? you might need to update some other core pkgs to satisfy depends tho.

As much as I'm labelled a Fedora proponent, the Fedora kernel is not something I'd run on RHEL/CentOS. There's just too many support/changes. Building a RHEL kernel on Fedora is one thing (which I've done to show that you can build RHEL out of Fedora, with just a few SRPMS from RHEL for kernel, etc...). But going the other way is a whole different ballgame -- Fedora kernels don't take to RHEL systems well.

If you want Fedora features, IMHO, it's best to rebuild from the RHEL/CentOS kernel, patching in what you need -- sparringly -- from the Fedora kernels. Yes, this is involved.

I think Johnny's work on getting a SGI guy on-board is probably the best bet to good XFS support. When Red Hat sees that someone is pro-actively working on solid XFS support for their RHEL kernels, I sincerely hope they take more interest (even if unofficial/unsupported).

I would almost argue that there should be just a RHEL kernel with XFS added, and not everything added. But I am in no position with CentOS' development to suggest such.

Matt Hyclak hyclak@math.ohiou.edu wrote:

I tried this the other day and it builds ok. On install it wanted a bunch of updated SELinux stuff. I started down the path, but the checkpolicy src.rpm refused to build, so I gave up for now.

Yeah, there's just too much different between the Fedora and RHEL kernels.

Les Mikesell wrote:

...

If you want Fedora features, IMHO, it's best to rebuild from the RHEL/CentOS kernel, patching in what you need -- sparringly -- from the Fedora kernels. Yes, this is involved.

It's not so much 'fedora' features I want as it is a later kernel rev. The www.linux1394.org site says that major changes were made in kernel 2.6.12, but I don't think it really works before 2.6.13 (and I'm not completely convinced there yet either...). But, the current FC4 at least seems much better than any earlier 2.6 version.

I am not sure if much of that stuff is going to make it into EL4 codebase. It _might_ help if you could perhaps attempt a backport and submit patches upstream.

Alternatively, if its possible to build some of this functionality into byte sized rpm's - we could perhaps build and host in CentOSPlus. I dont have the time to look at this at the moment, and I know Johnny and Pasi are pretty busy as well. Would someone like to contribute ?

- K

Les Mikesell lesmikesell@gmail.com wrote:

It's not so much 'fedora' features I want as it is a later kernel rev. The www.linux1394.org site says that major changes were made in kernel 2.6.12, but I don't think it really works before 2.6.13 (and I'm not completely convinced there yet either...). But, the current FC4 at least seems much better than any earlier 2.6 version.

Well, I'd try to stick with the latest Fedora Core 3 kernel when building for RHEL/CentOS 4:

http://download.fedora.redhat.com/pub/fedora/linux/core/updates/3/SRPMS/kern...

I know it's only version 2.6.12-1.1380, while FC4 has 2.6.13-1.1520. The 2.6.12-1.1380 release is 2.6.12.5 with some 2.6.12.6pre, a few 2.6.13 and other pataches. It's worth a shot versus the FC4 kernel.

Ajay Sharma ssharma@revsharecorp.com wrote:

I'm not a 'filesystem' guy, but is my assumption correct that XFS is great for large files and reiserfs is good for a ton of tiny files?

I'm not going to get deep into that. XFS has lots of features to avoid fragmentation and other issues. Some of those features tend to be more of an issue when you have lots of smaller, temporary files. But XFS is great for filesystems where you have a combination of small and large -- far better than most other implementations.

The reason *I* like to run XFS are:

#1 Structure hasn't changed in 10 years #2 Very, very trusted off-line repair (if on-line fsck detects an issue) -- largely because of #1 (hasn't changed in 10 years!) #3 On-line fsck, On-line fragmentor, On-line copy/dump #4 Extended Attributes (EAs) for things like Access Control Lists (ACLs), Quotas and SELinux are natively supported in inodes -- which means on-line copy/dump transfers them

On my mail server, I used reiserfs. Is there a better (faster) filesystem choice here?

ReiserFS doesn't use a traditional UNIX inode layout and requires various support modules to emulate them for NFS, Quotas, EAs, etc... And many of those features are broken.

But my #1 issue with ReiserFS has been the constant structural changes. Even if you trust the journal, if a journal replay doesn't resolve all consistencies, I've regularly run into the issue where the off-line fsck tools are not "up-to-date" with structural changes.

My first move _before_ running any fsck on ReiserFS is to do a full dd of the slice. Why? Because 9 times out of 10, I'm going to lose the filesystem when I run reiser.fsck.

And on my MythTV box at home, I used XFS because the only thing on the partition is large video files.

The problem with XFS is the lack of support by the distro vendors. I don't trust the stock kernel XFS implementation, and I don't trust vendors to include the proper user-space support.

With Red Hat and kernel 2.6, that 4KiB stacks is the main issue SGI is having. If an SGI XFS team member addresses that, then maybe it's the start of Red Hat's interest.

The last XFS system I put into "heavy production" was a RHL7.3/XFS1.2 implementation. I tested a RHL9/XFS1.3 system with lighter duties. Ironically, once XFS went into the stock 2.4 kernel/backport, it was far worse -- the 2.6 release is not what I expected either, but at least it's not as bad.

There are severe limitations to Ext3 that ReiserFS v3 doesn't solve, and ReiserFS v4 still has a lot of the same compatibility issues of ReiserFS v3. So AFAIAC, professionally, XFS is the only filesystem that augments Ext3 well.

Dan Pritts danno@internet2.edu wrote:

How current is this experience?

I've never tried ReiserFS on Red Hat. But it was as current as SuSE Linux 9.x and Mandrake Linux 9.x. Prior to Mandrake Linux 9.x, I found Mandrake notorious for not keeping the reiserfs tools consistent with their kernels.

I hear from proponents that reiser admittedly had problems in early days but they've cleaned up their act.

Linus forced them to stop changing structures so radically so often. But still, there are still a lot of kernel-driver changes that don't always make it into the mkfs.reiserfs off-line tools.

Let me say that again ... I *DO* believe the kernel implementation of ReiserFS is quite *RELIABLE*, maintaining good consistency and an effective meta-data journal (never tried full-data with it). Other than various feature support, I've _never_ had a problem there.

*BUT* if you find yourself in a pickle where the filesystem cannot be made consistent by the journal, and have to do a full fsck.reiserfs -- _avoid_ throwing that "-y" option. 9 times out of 10, you're going to have issues.

Furthermore, if you use a _stock_ kernel, instead of relying on the distro's, then _you_ are responsible for making sure you have the appropriate reiserfs user-space/off-line tools for that kernel implementation. With Ext3 and XFS, their structures virtually never change, so you're typically safe -- or always safe by upgrading to the latest user-space/off-line tools for those filesystems.

Which is why I prefer filesystems that don't constantly change in structure.

Can you elaborate? I thought that 2.6 kernels had merged the mainline XFS stuff.

They did. Much of the support required in the kernel for XFS was added in the 2.5 series. Many other filesystems also use that support to. But there is a lot of XFS errata if you look through the reports and revisions. ;->

In fact, I've been running XFS on the Fedora Core 2+ releases with no reliability issues -- but I'm not running anything serious on them. Unfortunately, I've run into NFS issues. And no one seems to trust XFS on 4K stacks, which Fedora Core does use.

As far as the kernel 2.4 backport, don't even bother. I've seen a lot of people with lots of problems, and the kernel 2.4 errata for XFS seems rather scary.

I can't find any discussion of problems on the XFS web site

Join the mailing lists. ;->

and the "xfs/download/latest" area on oss.sgi.com has files dated 2003.

Yes, because the last "official" release was for Red Hat Linux 9. The official releases for Red Hat Linux 7.3 and 9 are ones I actually still have running in production (nearly all are 7.3, XFS 1.2). Those kernels are SGI's own 2.4 kernel with their own XFS mergers (pre-backport from 2.6 that is now in the stock 2.4 kernel).

Everything since has been in SGI's CVS tree for XFS. The XFS team maintains their own, _full_ kernel tree in CVS. I seriously _doubt_ distros are pulling in all those SGI changes into their kernels. They are most likely just relying on the stock kernel XFS work.

Which is _not_ synchronized with more recent XFS work AFAICT.

On Thu, Oct 27, 2005 at 05:38:57PM +0100, Karanbir Singh enlightened us:

Matt Hyclak wrote:

...

...

You should be able to just grab the sources from download.fedora.redhat.com and rebuild ? you might need to update some other core pkgs to satisfy depends tho.

I tried this the other day and it builds ok. On install it wanted a bunch of updated SELinux stuff. I started down the path, but the checkpolicy src.rpm refused to build, so I gave up for now.

What functionality are you looking to bring in with a newer kernel ?

Personally, none. I was trying to help someone in the IRC channel with the sym53c8XX series SCSI controller that apparently broke/regressed somewhere between 2.6.5 and 2.6.9 development. I tried both bringing the Fedora kernel over to CentOS-4 and patching in the driver from FC4 into 2.6.9-22. Neither have worked so far, but I decided to keep at it today just for S&G.

Matt