What would be the easiest way to upgrade 2000 servers from RedHat 9 to Fedora or RedHat Enterprise/CentOS? Also, 1/2 of these systems have 1 TB data partition that cannot be destroyed.
Would an upgrade option work via Kickstart?
sudo Yang wrote:
What would be the easiest way to upgrade 2000 servers from RedHat 9 to Fedora or RedHat Enterprise/CentOS? Also, 1/2 of these systems have 1 TB data partition that cannot be destroyed.
Would an upgrade option work via Kickstart?
Wow, are you working for Google? :).
You should tell us about applications that run on it. Is a backup of the 1 TB partition possible? Is downtime possible for 1 server at the time?
I would recommend against fedora and tell you to go with CentOS (and maybe send a little donation/offer mirror). You'll thank yourself for the long life of updates and stability.
On Wed, 2005-08-03 at 10:26 -0400, Ugo Bellavance wrote:
sudo Yang wrote:
Gotta ask - is "sudo" a proper name or a nickname?
What would be the easiest way to upgrade 2000 servers from RedHat 9 to Fedora or RedHat Enterprise/CentOS? Also, 1/2 of these systems have 1 TB data partition that cannot be destroyed.
Would an upgrade option work via Kickstart?
That would be my guess, but I've never dealt with anything close to that magnitude of problem.
Wow, are you working for Google? :).
You should tell us about applications that run on it.
Also curious.
Is a backup of the 1 TB partition possible? Is downtime possible for 1 server at the time?
I would recommend against fedora and tell you to go with CentOS (and maybe send a little donation/offer mirror). You'll thank yourself for the long life of updates and stability.
I STRONGLY agree. Would not even consider Fedora for this large an operation. It's a nice platform to play with, but I wouldn't want to bet my livelihood on a "perpetual Beta" like FC. Please report your experiences when you make the move.
Phil
On 8/3/05, Phil Schaffner Philip.R.Schaffner@nasa.gov wrote:
On Wed, 2005-08-03 at 10:26 -0400, Ugo Bellavance wrote:
sudo Yang wrote:
Gotta ask - is "sudo" a proper name or a nickname?
Just a nickname.
What would be the easiest way to upgrade 2000 servers from RedHat 9 to Fedora or RedHat Enterprise/CentOS? Also, 1/2 of these systems have 1 TB data partition that cannot be destroyed.
Would an upgrade option work via Kickstart?
That would be my guess, but I've never dealt with anything close to that magnitude of problem.
Wow, are you working for Google? :).
You should tell us about applications that run on it.
Also curious.
Is a backup of the 1 TB partition possible? Is downtime possible for 1 server at the time?
I would recommend against fedora and tell you to go with CentOS (and maybe send a little donation/offer mirror). You'll thank yourself for the long life of updates and stability.
I STRONGLY agree. Would not even consider Fedora for this large an operation. It's a nice platform to play with, but I wouldn't want to bet my livelihood on a "perpetual Beta" like FC. Please report your experiences when you make the move.
We rely heavily on ReiserFS. Unfortunately, RedHat Enterprise and CentOS do not support it. We started out with RedHat 6.x then 7.1 which does not support any journaling file system at all. We had to add ReiserFS support ourselves, so I guess we could do the same here. I know CentOS has an unsupported kernel that supports ReiserFS, unfortunately it's not integrated into Anaconda for automated kickstart installation.
Why ReiserFS, it's more convenient and we've found it to work better with large file systems. These features are extremely useful in ReiserFS: dynamic inode creation, negligible time to create file system of any size, large file and filesystem support, no mandatory fsck (ext3 forces you to do this once in a while, unless you remember to reset it before rebooting). When ReiserFS 4 reaches maturity, we're planning to switch to it (atomic operations, metadata journaling, ... nice :).
Phil
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
sudo Yang wrote:
We rely heavily on ReiserFS. Unfortunately, RedHat Enterprise and CentOS do not support it.
See centosplus repository
http://mirror.centos.org/centos/4/centosplus/Readme.txt
The kernel in there supports it. You could also compile you own kernel (i know, it is not obvious).
Ugo,
hmmmm at first i was saying to myself, well sudo said that he knew about the riserfs support in centosplus directory but that he cant do that with kickstart. Now i see what you are talking about, use kickstart and then do a yum update kernel(for riserfs) and then reboot. ah i see said the blind man to the deaf man.
--- Ugo Bellavance ugob@camo-route.com wrote:
sudo Yang wrote:
We rely heavily on ReiserFS. Unfortunately,
RedHat Enterprise and
CentOS do not support it.
See centosplus repository
http://mirror.centos.org/centos/4/centosplus/Readme.txt
The kernel in there supports it. You could also compile you own kernel (i know, it is not obvious).
-- Ugo
-> Please don't send a copy of your reply by e-mail. I read the list. -> Please avoid top-posting, long signatures and HTML, and cut the irrelevant parts in your replies.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Steven
"On the side of the software box, in the 'System Requirements' section, it said 'Requires Windows or better'. So I installed Linux."
Steven Vishoot sir_funzone@yahoo.com wrote:
Ugo, hmmmm at first i was saying to myself, well sudo said that he knew about the riserfs support in centosplus directory but that he cant do that with kickstart. Now i see what you are talking about, use kickstart and then do a yum update kernel(for riserfs) and then reboot. ah i see said the blind man to the deaf man.
Which is why I _never_ make my root (/) filesystem anything but Ext3. I can always use basically any kernel 2.2 or later Ext2 implementation to read it.
I also tend to make my /tmp and /var filesystems Ext3, but with 2-4 as many inodes. XFS has extents and other fragmentation reducing features, but the performance of those features are inversely proportional to the number of small files.
ReiserFS' design is fluid, which means it's _dangerous_ to boot an older kernel and mount it. And while it's kernel module and journaling _is_ good IMHO, if the journal replay ever fails, the off-line recovery tools seem to be ... how can I say this ... not always as "concurrent" with development of the kernel/journal code.
On 8/3/05, Bryan J. Smith b.j.smith@ieee.org wrote:
Steven Vishoot sir_funzone@yahoo.com wrote:
Ugo, hmmmm at first i was saying to myself, well sudo said that he knew about the riserfs support in centosplus directory but that he cant do that with kickstart. Now i see what you are talking about, use kickstart and then do a yum update kernel(for riserfs) and then reboot. ah i see said the blind man to the deaf man.
Which is why I _never_ make my root (/) filesystem anything but Ext3. I can always use basically any kernel 2.2 or later Ext2 implementation to read it.
Currently, we use ext3 for all file systems except for the DATA partition(s) which is where our critical data lives. The DATA partition(s) hold about 15-20 million files.
I also tend to make my /tmp and /var filesystems Ext3, but with 2-4 as many inodes. XFS has extents and other fragmentation reducing features, but the performance of those features are inversely proportional to the number of small files.
ReiserFS' design is fluid, which means it's _dangerous_ to boot an older kernel and mount it. And while it's kernel module and journaling _is_ good IMHO, if the journal replay ever fails, the off-line recovery tools seem to be ... how can I say this ... not always as "concurrent" with development of the kernel/journal code.
-- Bryan J. Smith | Sent from Yahoo Mail mailto:b.j.smith@ieee.org | (please excuse any http://thebs413.blogspot.com/ | missing headers) _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
sudo Yang wrote:
On 8/3/05, Bryan J. Smith b.j.smith@ieee.org wrote:
Steven Vishoot sir_funzone@yahoo.com wrote:
Ugo, hmmmm at first i was saying to myself, well sudo said that he knew about the riserfs support in centosplus directory but that he cant do that with kickstart. Now i see what you are talking about, use kickstart and then do a yum update kernel(for riserfs) and then reboot. ah i see said the blind man to the deaf man.
Which is why I _never_ make my root (/) filesystem anything but Ext3. I can always use basically any kernel 2.2 or later Ext2 implementation to read it.
Currently, we use ext3 for all file systems except for the DATA partition(s) which is where our critical data lives. The DATA partition(s) hold about 15-20 million files.
So there should be no problem upgrading using the CD, then update the kernel to centosplus', then reboot and mount your data partitions using ReiserFS?
The only downtime would be the yum update + reboot. You could probably do that on many machines at a time, maybe using a post-install script or using something like pssh.
sudo Yang sudoyang@gmail.com wrote:
Currently, we use ext3 for all file systems except for the DATA partition(s) which is where our critical data lives.
Same for myself.
The DATA partition(s) hold about 15-20 million files.
Definitely the realm of XFS.
One huge advantage of XFS is its structure. Like Ext2 (which Ext3 is based on), it hasn't changed since the mid-'90s. You can remove an XFS volume from Linux/x86-64 and bring it up on Irix/MIPS64, and vice-versa.
There has only been one major bug in XFS. It caught me on two of my /var filessytems (I should have been using Ext3 instead, I know better), and was quickly addressed shortly after I had it (with the XFS 1.1 release).
The reason why XFS wasn't adopted in kernel 2.4 was because of the massive amount of support required. The XFS kernel module was literally over 2MB (took forever to boot if it was in your initrd on some cards with slow BIOS Int13h disk services ;-). That support went in kernel 2.5.3+ (for 2.6), and was later backported to late 2.4.x releases (circa 2.4.25 I believe?).
It wasn't because of any lack of reliability or stability. I sure wish Red Hat would have moved to support it because, like you, Ext3 is a serious limitation with large filesystems.
ReiserFS v4 is not your answer. JFS -- ported from OS/2 instead of AIX (and lacking a lot of features) is definitely not your answer either.
On 8/3/05, Steven Vishoot sir_funzone@yahoo.com wrote:
Ugo,
hmmmm at first i was saying to myself, well sudo said that he knew about the riserfs support in centosplus directory but that he cant do that with kickstart. Now i see what you are talking about, use kickstart and then do a yum update kernel(for riserfs) and then reboot. ah i see said the blind man to the deaf man.
Keep in mind that the kernel used during the kickstart process (used to be called the BOOT kernel) has to support the file system type, otherwise you can't create the file system(s) during the kick process. Someone recommended installing a kernel that supports the file system then do mkfs using that kernel after the kick, but this seems kind of kludgy.
--- Ugo Bellavance ugob@camo-route.com wrote:
sudo Yang wrote:
We rely heavily on ReiserFS. Unfortunately,
RedHat Enterprise and
CentOS do not support it.
See centosplus repository
http://mirror.centos.org/centos/4/centosplus/Readme.txt
The kernel in there supports it. You could also compile you own kernel (i know, it is not obvious).
-- Ugo
-> Please don't send a copy of your reply by e-mail. I read the list. -> Please avoid top-posting, long signatures and HTML, and cut the irrelevant parts in your replies.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
Steven
"On the side of the software box, in the 'System Requirements' section, it said 'Requires Windows or better'. So I installed Linux." _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
sudo Yang wrote:
On 8/3/05, Steven Vishoot sir_funzone@yahoo.com wrote:
Ugo,
hmmmm at first i was saying to myself, well sudo said that he knew about the riserfs support in centosplus directory but that he cant do that with kickstart. Now i see what you are talking about, use kickstart and then do a yum update kernel(for riserfs) and then reboot. ah i see said the blind man to the deaf man.
Keep in mind that the kernel used during the kickstart process (used to be called the BOOT kernel) has to support the file system type, otherwise you can't create the file system(s) during the kick process. Someone recommended installing a kernel that supports the file system then do mkfs using that kernel after the kick, but this seems kind of kludgy.
Why would you need to create a FS if it is an upgrade?
On 8/3/05, Ugo Bellavance ugob@camo-route.com wrote:
sudo Yang wrote:
On 8/3/05, Steven Vishoot sir_funzone@yahoo.com wrote:
Ugo,
hmmmm at first i was saying to myself, well sudo said that he knew about the riserfs support in centosplus directory but that he cant do that with kickstart. Now i see what you are talking about, use kickstart and then do a yum update kernel(for riserfs) and then reboot. ah i see said the blind man to the deaf man.
Keep in mind that the kernel used during the kickstart process (used to be called the BOOT kernel) has to support the file system type, otherwise you can't create the file system(s) during the kick process. Someone recommended installing a kernel that supports the file system then do mkfs using that kernel after the kick, but this seems kind of kludgy.
Why would you need to create a FS if it is an upgrade?
Because we currently add about 5-10 new servers a month. Both upgrade and new installation have to be considered.
-- Ugo
-> Please don't send a copy of your reply by e-mail. I read the list. -> Please avoid top-posting, long signatures and HTML, and cut the irrelevant parts in your replies.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
sudo Yang wrote:
On 8/3/05, Ugo Bellavance ugob@camo-route.com wrote:
sudo Yang wrote:
On 8/3/05, Steven Vishoot sir_funzone@yahoo.com wrote:
Ugo,
hmmmm at first i was saying to myself, well sudo said that he knew about the riserfs support in centosplus directory but that he cant do that with kickstart. Now i see what you are talking about, use kickstart and then do a yum update kernel(for riserfs) and then reboot. ah i see said the blind man to the deaf man.
Keep in mind that the kernel used during the kickstart process (used to be called the BOOT kernel) has to support the file system type, otherwise you can't create the file system(s) during the kick process. Someone recommended installing a kernel that supports the file system then do mkfs using that kernel after the kick, but this seems kind of kludgy.
Why would you need to create a FS if it is an upgrade?
Because we currently add about 5-10 new servers a month. Both upgrade and new installation have to be considered.
But, in the case of an install, you cannot create the filesystem after the install?
On 8/3/05, Ugo Bellavance ugob@camo-route.com wrote:
sudo Yang wrote:
On 8/3/05, Ugo Bellavance ugob@camo-route.com wrote:
sudo Yang wrote:
On 8/3/05, Steven Vishoot sir_funzone@yahoo.com wrote:
Ugo,
hmmmm at first i was saying to myself, well sudo said that he knew about the riserfs support in centosplus directory but that he cant do that with kickstart. Now i see what you are talking about, use kickstart and then do a yum update kernel(for riserfs) and then reboot. ah i see said the blind man to the deaf man.
Keep in mind that the kernel used during the kickstart process (used to be called the BOOT kernel) has to support the file system type, otherwise you can't create the file system(s) during the kick process. Someone recommended installing a kernel that supports the file system then do mkfs using that kernel after the kick, but this seems kind of kludgy.
Why would you need to create a FS if it is an upgrade?
Because we currently add about 5-10 new servers a month. Both upgrade and new installation have to be considered.
But, in the case of an install, you cannot create the filesystem after the install?
You can by doing it yourself or with a script. Anything is doable -- just trying to determine the best way. Everything else seems kludgy unless it's integrated into Anaconda/kickstart.
-- Ugo
-> Please don't send a copy of your reply by e-mail. I read the list. -> Please avoid top-posting, long signatures and HTML, and cut the irrelevant parts in your replies.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
sudo Yang wrote:
On 8/3/05, Ugo Bellavance ugob@camo-route.com wrote:
sudo Yang wrote:
On 8/3/05, Ugo Bellavance ugob@camo-route.com wrote:
sudo Yang wrote:
On 8/3/05, Steven Vishoot sir_funzone@yahoo.com wrote:
Ugo,
hmmmm at first i was saying to myself, well sudo said that he knew about the riserfs support in centosplus directory but that he cant do that with kickstart. Now i see what you are talking about, use kickstart and then do a yum update kernel(for riserfs) and then reboot. ah i see said the blind man to the deaf man.
Keep in mind that the kernel used during the kickstart process (used to be called the BOOT kernel) has to support the file system type, otherwise you can't create the file system(s) during the kick process. Someone recommended installing a kernel that supports the file system then do mkfs using that kernel after the kick, but this seems kind of kludgy.
Why would you need to create a FS if it is an upgrade?
Because we currently add about 5-10 new servers a month. Both upgrade and new installation have to be considered.
But, in the case of an install, you cannot create the filesystem after the install?
You can by doing it yourself or with a script. Anything is doable -- just trying to determine the best way. Everything else seems kludgy unless it's integrated into Anaconda/kickstart.
Isn't there a post-install script option in kickstart? I wonder if it could support an action (create FS) after a reboot (for the new kernel).
-- Ugo
-> Please don't send a copy of your reply by e-mail. I read the list. -> Please avoid top-posting, long signatures and HTML, and cut the irrelevant parts in your replies.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 8/3/05, Ugo Bellavance ugob@camo-route.com wrote:
sudo Yang wrote:
On 8/3/05, Ugo Bellavance ugob@camo-route.com wrote:
sudo Yang wrote:
On 8/3/05, Ugo Bellavance ugob@camo-route.com wrote:
sudo Yang wrote:
On 8/3/05, Steven Vishoot sir_funzone@yahoo.com wrote:
>Ugo, > >hmmmm at first i was saying to myself, well sudo said >that he knew about the riserfs support in centosplus >directory but that he cant do that with kickstart. Now >i see what you are talking about, use kickstart and >then do a yum update kernel(for riserfs) and then >reboot. ah i see said the blind man to the deaf man.
Keep in mind that the kernel used during the kickstart process (used to be called the BOOT kernel) has to support the file system type, otherwise you can't create the file system(s) during the kick process. Someone recommended installing a kernel that supports the file system then do mkfs using that kernel after the kick, but this seems kind of kludgy.
Why would you need to create a FS if it is an upgrade?
Because we currently add about 5-10 new servers a month. Both upgrade and new installation have to be considered.
But, in the case of an install, you cannot create the filesystem after the install?
You can by doing it yourself or with a script. Anything is doable -- just trying to determine the best way. Everything else seems kludgy unless it's integrated into Anaconda/kickstart.
Isn't there a post-install script option in kickstart? I wonder if it could support an action (create FS) after a reboot (for the new kernel).
There is both a pre and a post install, however the kernel that's used to kickstart a system has to support the file system type. In other words, you can't create a ReiserFS file system in pre or post unless the kernel that's used during the kick supports ReiserFS.
-- Ugo
-> Please don't send a copy of your reply by e-mail. I read the list. -> Please avoid top-posting, long signatures and HTML, and cut the irrelevant parts in your replies.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-- Ugo
-> Please don't send a copy of your reply by e-mail. I read the list. -> Please avoid top-posting, long signatures and HTML, and cut the irrelevant parts in your replies.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On 8/3/05, sudo Yang sudoyang@gmail.com wrote:
There is both a pre and a post install, however the kernel that's used to kickstart a system has to support the file system type. In other words, you can't create a ReiserFS file system in pre or post unless the kernel that's used during the kick supports ReiserFS.
Sounds like your best option in the post-install, use yum to install the kernel rpm that gives ReiserFS support, and then on first boot, have the system create the filesystem for you.
bnm
sudo Yang sudoyang@gmail.com wrote:
We rely heavily on ReiserFS. Unfortunately, RedHat Enterprise and CentOS do not support it.
There's a reason for this and a reason why Fedora makes you run an installer-time option to enable it.
We started out with RedHat 6.x then 7.1 which does not support any journaling file system at all.
I was fairly certain that Ext3 shipped with Red Hat Linux 7, especially 7.1 which was kernel 2.4. Ext3 went into the stock kernel as of 2.4.15. Although ReiserFS went into the stock kernel as of 2.4.1, it was still missing serious features that Ext3 had.
We had to add ReiserFS support ourselves, so I guess we could do the same here.
Any reason you went ReiserFS?
Back in the kernel 2.2 era, even SuSE recommended I not deploy it, and go with VA Linux / Ext3 kernels instead. I was glad that I did -- never a hiccup (although it was full data journaling back then).
I know CentOS has an unsupported kernel that supports ReiserFS, unfortunately it's not integrated into Anaconda for automated kickstart installation. Why ReiserFS, it's more convenient and we've found it to work better with large file systems.
Actually, if you're working with large filesystems, XFS is a better solution IMHO. It has had the best feature support history of any journaling filesystem, even over Ext3 in many cases. The only issue XFS had was the lack of a lot of support code -- stuff that went in circa 2.5.3+, and is now standard in 2.6 (as well as backported to late 2.4).
I've been running XFS since Red Hat Linux 7.1.
These features are extremely useful in ReiserFS: dynamic inode creation,
XFS
negligible time to create file system of any size,
XFS
large file and filesystem support,
Oh, definitely XFS -- especially versus ReiserFS v3 at the time.
no mandatory fsck (ext3 forces you to do this once in a while, unless you remember to reset it before rebooting).
You can use "tune2fs -i 0" and "tune2fs -c -1" to turn it off, _permanently_.
When ReiserFS 4 reaches maturity, we're planning to switch to it (atomic operations, metadata journaling, ... nice :).
Did I mention XFS? ;->
XFS was ported whole from Irix, true, full UNIX filesystem design that has been unchanged since 1994. All major features were 100% compatible with Linux from day 1 -- NFS, Quotas, SELinux (when it was introduced later), etc..., as well as POSIX ACLs.
In fact, most of the general Virtual Filesystem (VFS) layer features that all filesystems benefit from (even if JFS and ReiserFS don't implement them yet) was thanx to SGI's contributions to 2.5's development.
On 8/3/05, Bryan J. Smith b.j.smith@ieee.org wrote:
sudo Yang sudoyang@gmail.com wrote:
We rely heavily on ReiserFS. Unfortunately, RedHat Enterprise and CentOS do not support it.
There's a reason for this and a reason why Fedora makes you run an installer-time option to enable it.
We started out with RedHat 6.x then 7.1 which does not support any journaling file system at all.
I was fairly certain that Ext3 shipped with Red Hat Linux 7, especially 7.1 which was kernel 2.4. Ext3 went into the stock kernel as of 2.4.15. Although ReiserFS went into the stock kernel as of 2.4.1, it was still missing serious features that Ext3 had.
ext3 wasn't supported in RH 7.1. In fact, I don't think the '--fstype' option existed for the KS file.
We had to add ReiserFS support ourselves, so I guess we could do the same here.
Any reason you went ReiserFS?
Back in the kernel 2.2 era, even SuSE recommended I not deploy it, and go with VA Linux / Ext3 kernels instead. I was glad that I did -- never a hiccup (although it was full data journaling back then).
I know CentOS has an unsupported kernel that supports ReiserFS, unfortunately it's not integrated into Anaconda for automated kickstart installation. Why ReiserFS, it's more convenient and we've found it to work better with large file systems.
Actually, if you're working with large filesystems, XFS is a better solution IMHO. It has had the best feature support history of any journaling filesystem, even over Ext3 in many cases. The only issue XFS had was the lack of a lot of support code -- stuff that went in circa 2.5.3+, and is now standard in 2.6 (as well as backported to late 2.4).
I've been running XFS since Red Hat Linux 7.1.
These features are extremely useful in ReiserFS: dynamic inode creation,
XFS
negligible time to create file system of any size,
XFS
large file and filesystem support,
Oh, definitely XFS -- especially versus ReiserFS v3 at the time.
no mandatory fsck (ext3 forces you to do this once in a while, unless you remember to reset it before rebooting).
You can use "tune2fs -i 0" and "tune2fs -c -1" to turn it off, _permanently_.
When ReiserFS 4 reaches maturity, we're planning to switch to it (atomic operations, metadata journaling, ... nice :).
Did I mention XFS? ;->
XFS was ported whole from Irix, true, full UNIX filesystem design that has been unchanged since 1994. All major features were 100% compatible with Linux from day 1 -- NFS, Quotas, SELinux (when it was introduced later), etc..., as well as POSIX ACLs.
In fact, most of the general Virtual Filesystem (VFS) layer features that all filesystems benefit from (even if JFS and ReiserFS don't implement them yet) was thanx to SGI's contributions to 2.5's development.
This is very good info about XFS, so thanks for the info. I know it has made it into the standard kernel tree. How's the development effort on it as of late? Wonder why RedHat chose not to support anything else except for ext2 and ext3.
How stable are user-land tools for dealing with corrupted XFS filesystems? This is one area of ReiserFS that still needs a lot of work. We've been running ReiserFS in very active systems for the past 4+ years. For the most part, it has been fairly good to us. We've lost about 5 systems we could not recover using these tools (sometimes these tools did more harm than good).
-- Bryan J. Smith | Sent from Yahoo Mail mailto:b.j.smith@ieee.org | (please excuse any http://thebs413.blogspot.com/ | missing headers) _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
sudo Yang sudoyang@gmail.com wrote:
ext3 wasn't supported in RH 7.1.
The Anaconda installer didn't support it. But the kernels had support for it.
You could make any Ext2 filesystem into Ext3 very easily, except the root filesystem itself.
This is very good info about XFS, so thanks for the info. I know it has made it into the standard kernel tree.
IMHO, XFS has always been the most reliable/stable journaling filesystem in Linux. The lack of advanced features required for it in the Linux 2.4 kernel itself was always the issue. SGI got on-board with the 2.5 development really quick, and a lot of the VFS features in 2.6 owe their thanx to SGI.
How's the development effort on it as of late?
Understand that XFS development was pretty straight forward. Unlike Ext3, they had already dealt with the quota and ACL issues on Irix, and written that code. Unlike ReiserFS, the structure hadn't changed a bit. And unlike JFS from OS/2, XFS came from Irix, a UNIX platform. [ IBM's move to port JFS from OS/2 in 1999, instead of AIX, had to do with Monterey, their joint contract with SCO that IBM broke later ]
Wonder why RedHat chose not to support anything else except for ext2 and ext3.
Proven, reliable, etc..., and Tweedie (who largely came up with Ext3) works at Red Hat. I love the fact that I can always break down to a full Ext2 fsck if I need to for Ext3.
One of the reasons I refuse to use ReiserFS has nothing to do with its kernel/journal code -- which from what I've seen, is far better than JFS and many others (possibly even Ext3) -- but the off-line tools _lag_ the kernel/journal code.
I.e., ReiserFS is typically fine if the journal recovers. And ReiserFS does a good job in testing if it should use its journal are not (arguably better than Ext3). But the off-lines tools -- they are seemingly _never_ "up-to-date" so if the journal can't recovery, you're at their mercy.
How stable are user-land tools for dealing with corrupted XFS filesystems?
xfs_repair is a crapload better than ReiserFS' fsck. I have never, ever lost an Ext2/Ext3 or XFS filesystem to an fsck.ext2 or xfs_repair run. The latter was even able to repair the 2 /var filesystems I had corruption on back with the XFS 1.0 bug. And the former has saved me when I've had physical disk errors.
I've had toast after toast after toast with ReiserFS' fsck. In fact, when it comes to an inconsistent ReiserFS that (correctly) won't replay its journal, I clone it, mount it read-only and pull all the data off I can -- even though it's inconsistent. Because so many ReiserFS fsck have left it totally inconsistant and umountable on me.
This is one area of ReiserFS that still needs a lot of work.
Thanx because Hans Reiser believes filesystems should be redesigned every 5 years.
Ext2 (including Ext3) and XFS have had the same structure since the mid-'90s. Ext3 underwent a run-time change at kernel 2.2 (circa 1998), and XFS underweant a run-time change at XFS 1.1 (i.e., circa 2002 / Red Hat Linux 7.2).
We've been running ReiserFS in very active systems for the past 4+ years. For the most part, it has been fairly good to us.
As long as the ReiserFS journal can recover, I think it's a great OS. Reiser & team put in the time to make a good driver and recovery logic. I won't fault them there, and I'd say it's probably better than Ext3's basic approach.
We've lost about 5 systems we could not recover using these tools (sometimes these tools did more harm than good).
Exactly! Because the focus is _never_ on the off-line tools. And it is unlike that will _ever_ change.
On 8/3/05, Bryan J. Smith b.j.smith@ieee.org wrote:
sudo Yang sudoyang@gmail.com wrote:
ext3 wasn't supported in RH 7.1.
The Anaconda installer didn't support it. But the kernels had support for it.
You could make any Ext2 filesystem into Ext3 very easily, except the root filesystem itself.
This is very good info about XFS, so thanks for the info. I know it has made it into the standard kernel tree.
IMHO, XFS has always been the most reliable/stable journaling filesystem in Linux. The lack of advanced features required for it in the Linux 2.4 kernel itself was always the issue. SGI got on-board with the 2.5 development really quick, and a lot of the VFS features in 2.6 owe their thanx to SGI.
Does XFS do data journaling (ReiserFS 4 is supposed to do this at minimal cost)?
How's the development effort on it as of late?
Understand that XFS development was pretty straight forward. Unlike Ext3, they had already dealt with the quota and ACL issues on Irix, and written that code. Unlike ReiserFS, the structure hadn't changed a bit. And unlike JFS from OS/2, XFS came from Irix, a UNIX platform. [ IBM's move to port JFS from OS/2 in 1999, instead of AIX, had to do with Monterey, their joint contract with SCO that IBM broke later ]
Wonder why RedHat chose not to support anything else except for ext2 and ext3.
Proven, reliable, etc..., and Tweedie (who largely came up with Ext3) works at Red Hat. I love the fact that I can always break down to a full Ext2 fsck if I need to for Ext3.
One of the reasons I refuse to use ReiserFS has nothing to do with its kernel/journal code -- which from what I've seen, is far better than JFS and many others (possibly even Ext3) -- but the off-line tools _lag_ the kernel/journal code.
I.e., ReiserFS is typically fine if the journal recovers. And ReiserFS does a good job in testing if it should use its journal are not (arguably better than Ext3). But the off-lines tools -- they are seemingly _never_ "up-to-date" so if the journal can't recovery, you're at their mercy.
How stable are user-land tools for dealing with corrupted XFS filesystems?
xfs_repair is a crapload better than ReiserFS' fsck. I have never, ever lost an Ext2/Ext3 or XFS filesystem to an fsck.ext2 or xfs_repair run. The latter was even able to repair the 2 /var filesystems I had corruption on back with the XFS 1.0 bug. And the former has saved me when I've had physical disk errors.
I've had toast after toast after toast with ReiserFS' fsck. In fact, when it comes to an inconsistent ReiserFS that (correctly) won't replay its journal, I clone it, mount it read-only and pull all the data off I can -- even though it's inconsistent. Because so many ReiserFS fsck have left it totally inconsistant and umountable on me.
This is one area of ReiserFS that still needs a lot of work.
Thanx because Hans Reiser believes filesystems should be redesigned every 5 years.
Ext2 (including Ext3) and XFS have had the same structure since the mid-'90s. Ext3 underwent a run-time change at kernel 2.2 (circa 1998), and XFS underweant a run-time change at XFS 1.1 (i.e., circa 2002 / Red Hat Linux 7.2).
We've been running ReiserFS in very active systems for the past 4+ years. For the most part, it has been fairly good to us.
As long as the ReiserFS journal can recover, I think it's a great OS. Reiser & team put in the time to make a good driver and recovery logic. I won't fault them there, and I'd say it's probably better than Ext3's basic approach.
We've lost about 5 systems we could not recover using these tools (sometimes these tools did more harm than good).
Exactly! Because the focus is _never_ on the off-line tools. And it is unlike that will _ever_ change.
-- Bryan J. Smith | Sent from Yahoo Mail mailto:b.j.smith@ieee.org | (please excuse any http://thebs413.blogspot.com/ | missing headers) _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Wed, 2005-08-03 at 13:14 -0700, sudo Yang wrote:
Does XFS do data journaling
Nope. Only Ext3 and ReiserFS offer full data journaling.
(ReiserFS 4 is supposed to do this at minimal cost)?
I couldn't find anything on this at the ReiserFS site.
On 8/3/05, Ugo Bellavance ugob@camo-route.com wrote:
sudo Yang wrote:
What would be the easiest way to upgrade 2000 servers from RedHat 9 to Fedora or RedHat Enterprise/CentOS? Also, 1/2 of these systems have 1 TB data partition that cannot be destroyed.
Would an upgrade option work via Kickstart?
Wow, are you working for Google? :).
No, not Google. We're in a completely different market. We index almost as many documents a google. During a search/query, Google is not required to return all documents -- we do. Google only indexes 10,000 terms/tokens in a document, we have no limit. If the document is greater than 101K (after conversion), Google will not index; we have no limit. This info is from friends inside of Google. Compliance market is completely different.
You should tell us about applications that run on it. Is a backup of the 1 TB partition possible? Is downtime possible for 1 server at the time?
Our systems are mirrored (two servers contain the same data). However, it would take too long to do this procedure on 2000 servers, not to mention the fact that this would be an operational nightmare.
I would recommend against fedora and tell you to go with CentOS (and maybe send a little donation/offer mirror). You'll thank yourself for the long life of updates and stability.
Agree. I had to mention Fedora because it's a "development" release so ideas from here could be used.
-- Ugo
-> Please don't send a copy of your reply by e-mail. I read the list. -> Please avoid top-posting, long signatures and HTML, and cut the irrelevant parts in your replies.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-
Brian MacLeod -
Bryan J. Smith -
Phil Schaffner -
Steven Vishoot -
sudo Yang -
Ugo Bellavance