I am attempting to implement XFS on a new system.
System: Supermicro SC846 TQ-R900B - rack-mountable SUPERMICRO X7DWN+ - motherboard 3ware 9650SE-24M8 - storage controller 10 Hitachi DeskStar 7K1000 - hard drive - 1 TB 8GB Ram 2 Intel Quad-Core Xeon E5420 / 2.5 GHz processor
Installed Centos 5.1 X86 64 from DVD. System on /dev/sda1 250GB ext3 (raid 5). /home will be on /dev/sdb1 over 7TB XFS.
Kernel version issue
---------------------------------
[root@csfs50 work]# yum install kmod-xfs.x86_64 Loading "installonlyn" plugin Setting up Install Process Setting up repositories Reading repository metadata in from local files Parsing package install arguments Resolving Dependencies --> Populating transaction set with selected packages. Please wait. ---> Downloading header for kmod-xfs to pack into transaction set. kmod-xfs-0.4-1.2.6.18_53. 100% |=========================| 2.8 kB 00:00 ---> Package kmod-xfs.x86_64 0:0.4-1.2.6.18_53.1.19.el5 set to be installed --> Running transaction check --> Processing Dependency: kernel-x86_64 = 2.6.18-53.1.19.el5 for package: kmod-xfs --> Restarting Dependency Resolution with new changes. --> Populating transaction set with selected packages. Please wait. ---> Downloading header for kernel to pack into transaction set. kernel-2.6.18-53.1.19.el5 100% |=========================| 256 kB 00:00 ---> Package kernel.x86_64 0:2.6.18-53.1.19.el5 set to be installed --> Running transaction check
Dependencies Resolved
============================================================================= Package Arch Version Repository Size ============================================================================= Installing: kmod-xfs x86_64 0.4-1.2.6.18_53.1.19.el5 extras 253 k Installing for dependencies: kernel x86_64 2.6.18-53.1.19.el5 updates 15 M
Transaction Summary ============================================================================= Install 2 Package(s) Update 0 Package(s) Remove 0 Package(s)
Total download size: 16 M Is this ok [y/N]: y Downloading Packages: (1/2): kmod-xfs-0.4-1.2.6 100% |=========================| 253 kB 00:00 (2/2): kernel-2.6.18-53.1 100% |=========================| 15 MB 00:02 Running Transaction Test Finished Transaction Test
Transaction Check Error: package kernel-2.6.18-53.1.21.el5 (which is newer than kernel-2.6.18-53.1.19.el5) is already installed
Error Summary -------------
mslist@opcenter.net wrote:
I am attempting to implement XFS on a new system.
System: Supermicro SC846 TQ-R900B - rack-mountable SUPERMICRO X7DWN+ - motherboard 3ware 9650SE-24M8 - storage controller 10 Hitachi DeskStar 7K1000 - hard drive - 1 TB 8GB Ram 2 Intel Quad-Core Xeon E5420 / 2.5 GHz processor
Installed Centos 5.1 X86 64 from DVD. System on /dev/sda1 – 250GB ext3 (raid 5). /home will be on /dev/sdb1 – over 7TB XFS.
Kernel version issue
[root@csfs50 work]# yum install kmod-xfs.x86_64 Loading "installonlyn" plugin Setting up Install Process Setting up repositories Reading repository metadata in from local files Parsing package install arguments Resolving Dependencies --> Populating transaction set with selected packages. Please wait. ---> Downloading header for kmod-xfs to pack into transaction set. kmod-xfs-0.4-1.2.6.18_53. 100% |=========================| 2.8 kB 00:00 ---> Package kmod-xfs.x86_64 0:0.4-1.2.6.18_53.1.19.el5 set to be installed --> Running transaction check --> Processing Dependency: kernel-x86_64 = 2.6.18-53.1.19.el5 for package: kmod-xfs --> Restarting Dependency Resolution with new changes. --> Populating transaction set with selected packages. Please wait. ---> Downloading header for kernel to pack into transaction set. kernel-2.6.18-53.1.19.el5 100% |=========================| 256 kB 00:00 ---> Package kernel.x86_64 0:2.6.18-53.1.19.el5 set to be installed --> Running transaction check
Dependencies Resolved
=============================================================================
Package Arch Version Repository Size
Installing: kmod-xfs x86_64 0.4-1.2.6.18_53.1.19.el5 extras 253 k Installing for dependencies: kernel x86_64 2.6.18-53.1.19.el5 updates 15 M
Transaction Summary
Install 2 Package(s) Update 0 Package(s) Remove 0 Package(s)
Total download size: 16 M Is this ok [y/N]: y Downloading Packages: (1/2): kmod-xfs-0.4-1.2.6 100% |=========================| 253 kB 00:00 (2/2): kernel-2.6.18-53.1 100% |=========================| 15 MB 00:02 Running Transaction Test Finished Transaction Test
Transaction Check Error: package kernel-2.6.18-53.1.21.el5 (which is newer than kernel-2.6.18-53.1.19.el5) is already installed
The problem is that the extras and centosplus items are on hold while work on CentOS-5.2.
I have not built the centosplus kernel for 2.6.18-53.1.21.el5 as we are using the builders for 5.2 and kernels take forever to build in the builders as the debuginfo files are hundreds of MBs in size each.
I also normally build all the extras kmods while I build the centosplus kernel, so they were also not yet done ... however I did go ahead and build the new kmods for drbd82, xfs, and kvm for the new 2.6.18-53.1.21.el5 kernel and those have now been pushed to the extras directory.
They should be synced to the external public mirrors in a couple hours, and should be on mirror.centos.org now here:
On Sat, May 31, 2008 at 1:16 PM, Johnny Hughes johnny@centos.org wrote:
I also normally build all the extras kmods while I build the centosplus kernel, so they were also not yet done ... however I did go ahead and build
I dont intend to blame anybody but kmod_xfs was a couple of days late for previous kernel update and I broke an xfs partition, as recorded in list archives.
In that thread, I was told to expect such things and test better because xfs was not in official brunch neither in rhel nor in centos.
Linux wrote:
On Sat, May 31, 2008 at 1:16 PM, Johnny Hughes johnny@centos.org wrote:
I also normally build all the extras kmods while I build the centosplus kernel, so they were also not yet done ... however I did go ahead and build
I dont intend to blame anybody but kmod_xfs was a couple of days late for previous kernel update and I broke an xfs partition, as recorded in list archives.
Good, because we can not support the extras and centosplus repositories in the same time frames as the main repositories.
In that thread, I was told to expect such things and test better because xfs was not in official brunch neither in rhel nor in centos.
IF you have required kernel modules, then you should probably set the kernels and the kmods as excluded and NOT update those automatically (using your yum.conf file).
You can then double check when the updates are available.
I ALWAYS manually upgrade my kernels on machines that require kmods. As I have said many times, add on repos are supported, but they are not supported within the same time frames.
I would also not use XFS in production ... but that is just me. If XFS was production ready, it would be in RHEL. Since it is turned on in Fedora and since it is purposely turned off in RHEL, one can reasonably conclude that the upstream people DO NOT THINK it is stable enough to use in production on RHEL. This is JUST my opinion :D
On Mon, 2 Jun 2008 at 7:03am, Johnny Hughes wrote
I would also not use XFS in production ... but that is just me. If XFS was production ready, it would be in RHEL. Since it is turned on in Fedora and since it is purposely turned off in RHEL, one can reasonably conclude that the upstream people DO NOT THINK it is stable enough to use in production on RHEL. This is JUST my opinion :D
IIRC, RH's stated reason (stated on the mailing lists in the midst of folks clamoring for XFS' inclusion) for not having XFS turned on in RHEL is *not* that it's not production ready. It's that they only have the resources (read: folks with knowledge in-depth enough to satisfy enterprise customers) to support 1 FS, and that's ext3.
Joshua Baker-LePain wrote:
On Mon, 2 Jun 2008 at 7:03am, Johnny Hughes wrote
I would also not use XFS in production ... but that is just me. If XFS was production ready, it would be in RHEL. Since it is turned on in Fedora and since it is purposely turned off in RHEL, one can reasonably conclude that the upstream people DO NOT THINK it is stable enough to use in production on RHEL. This is JUST my opinion :D
IIRC, RH's stated reason (stated on the mailing lists in the midst of folks clamoring for XFS' inclusion) for not having XFS turned on in RHEL is *not* that it's not production ready. It's that they only have the resources (read: folks with knowledge in-depth enough to satisfy enterprise customers) to support 1 FS, and that's ext3.
indeed, when I looked into using XFS for a large scale data store, I had several XFS 'gurus' (freenode xfs channel) strongly recommend only deploying it with the help of SGI consulting services, using a SGI distribution. Since at the time, SGI's long term viability was dubious (and its not improved any since then, this was about 2 years ago), I moved on. We are currently using Solaris 10 plus ZFS for this application, with satisfactory results (except some annoying problems with marvel88SX sata drivers but thats another issue entirely)