Why Redhat Choose ext3 For 7.2
mz001b writes "There is an interesting article from RH posted on LinuxToday discussing why they chose ext3 over the other available journaling filesystems (ReiserFS, xfs, jfs,...) for RH 7.2"
← Back to Stories (view on slashdot.org)
Linux still is about choice. You can choose Red Hat, or Debian, or Suse, or Mandrake, or Progeny, or whatever you want. Inside those choices, you can choose to install whatever packages you like. And you can choose whatever filesystem suits your fancy. Red Hat isn't telling you what works for you, and it isn't telling you that you shouldn't use a certain filesystem. It says that very plainly in the article. Please read them before posting drivel like this.
Every once in a while I like to masturbate a new word into my vocabulary, even if I don't know what it means.
why did they choose to use ext3 ?
ofcourse its the migration path. Users can choose to install ext3 and later if they want to they can choose to go back to ext2. forward and backwards compatiblity makes ext3 a much more friendly jouraling filesystem for businesses. Some of the intranet servers cannot risk to backup and hope the new filesystem to go up working alright. Ofcourse there are better journaling filesystems out there. But the choice to use ext3 is good one since, its mature,stable and easier to administrate and use. Easier to administrate and use the keywords here. Any kernel out there can read an ext3 partition without extra modules. So it definitely plays well with others. Is there any other journaling filesystem that can say this ?
I've been interested in upgrading the FS on the machines I manage here in the office, give or take about 15 servers. The fact of the matter is that it is no small job bringing down a production machine to change its filesystem. So, it sits with an unjournaled ext2 fs. Which is where it would sit, potentially forever until it left the production scope. The ability to upgrade the FS to ext3 without even a reboot, AND maintaining the security of being able to roll back those changes are more than enough to convince me that this is the best way to go.
If I push to have the systems upgraded, say to ReiserFS, and something goes wrong. I'm just plain f**ked. It's that simple. This offers me the ability to upgrade with a fraction of the risk. Which, considering RedHats duties to its customers, I think is the perfect decision.
Aaron
AaronCameron.net
I'm suprised that more people haven't said anything about XFS. I've been using for awhile now at home and on a production fileserver at work for awhile now and haven't experienced any problems. The only thing at all that has been a worry is the fact that Grub can not yet read XFS, so you have to create a small boot drive at the beginning. At least with XFS, the filesystem has already been designed and tested for years by SGI, and the only matter was porting it to Linux. From what I've seen with ReiserFS, they are still trying to decide on features and on how it is going to go about doing things. That's fine and all, but I don't want to end up having to backup and restore my filesystem a few times as they decide to impliment a new "everything and the kitchen sink" feature. If I'm doing something for file integrity and security, I'd rather have something that I know has been working for years now in a high performance environment. Just so this won't be considered offtopic, I would say that I can see why ext3 would be preferred by Redhat over Reiser (with the in-house development, and the easier migration), and hey, it will probably be "good enough" for most people (and certainly some kind of journaling is better than plain ext2), so hey, good for Redhat, and good for their users. I'll continue using XFS, but that's what's nice about choice anyway, right?
RedHat has been VERY good about not radically changing their platform between point releases so I'm not surprised to see this incremental filesystem improvement.
I would, however, be surprised to see them skip XFS, JFS or ReiserFS in their 8.0 release. It would make sense for them to add that capability at that time (and would allow the implementations to mature that much more).
-- James
James