Slashdot Mirror
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)
I've worked with ext2, ext3, and ReiserFS extensively, and I can say I've had vastly different results than what many people have _read and repeated_ here. Ext2 is a nice filesystem, assuming you don't have to worry about an unclean shutdown. I can't count the number of times I've lost a filesystem entirely because it was ACTUALLY doing something when the power was lost, or just 2.4's bad VM sending the machine into oblivion and the filesystem with it. Ext3 was nice when I used it once or twice, until I turned DMA on for the disk, at which point it started corrupting itself quite nicely (not a hardware issue, trust me). I would hope this is fixed by now, but I always found it to be a nice feature. ReiserFS, but comparison, has never failed me. I've used it extensively on production machines under 2.2 and 2.4, and been using knfsd since 2.4.6 was released (damn ext2 hooks in the code, completely ridiculous). Obviously, you should find what suits your needs best, but some of the flaming and outright incorrect claims I've seen recently are just ridiculous. See what works for you, not just what RedHat tells you. I remember when Linux was about choice, not about RedHat telling me that I shouldn't use a certain filesystem on my machine and not giving me the CHOICE of doing so.
Interested in open source engine management for your Subaru?
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 ?
You are missing a little from your math. Alan Cox is not relevant in this case.
Stephen Tweedie is. He is one of the top filesystem ext[23] hackers and is employed by Redhat. RedHat runs the mailing list for ext2 and ext3 stuff.
But mostly, ext3 allows new filesystems to be employed over old existing ones without a backup and re-creation of the file system. This means ext3 will be deployed (in the US) 10 times more than any other journaled file system.
As for speed, I think the ext[23] file systems, which are already fast, are going to catch up with the addition of an inode hash from Daniel Phillips. Or with his Tux2 file system which is in development. But really, unless you use directories with a large number of small files, ext2 and ReiserFS are not much different for speed.
Having an EASY upgrade path is the way. I also suspect Linus will add ext3 to the mainline kernels in another 2-3 kernel iterations, since the ext3 hackers are quite used to the appropriate methods for getting new code included.
... since Alan Cox (@redhat.com) had so many arguments over the Linux kernel Mailing List with Hans Reiser.
This thread is a good example.
I'm impressed that you were able to write that long paragraph in the three minutes since the article was posted, let alone read the message linked-to. But, I think that in your hurry, you missed a few key things, so I thought I'd quote them here for your benefit and the benefit of anyone else in too much of a rush:
Red Hat is just telling you what they think works -- not taking away any of your choices. They even ship the reiserfs tools. Perhaps you've fallen to the whole "Red Hat is too popular to be cool" thing?
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
Reiser performs better than ext2 mainly on two points:
ext2 uses a linear search algorithm to index directories while Reiser uses a hashtable. This makes handing of large (10000+ files) directories far more efficient. No more need for /home/h/he/hensema.
Reiserfs also packs together the 'tails' of files, meaning that multiple endings of files can occupy the same disk block. This saves space (less slack). The classic example where this works very well is a newsspool, containing hunderds of thousands of files sized typically around 4 KB.
I'm not sure wether the special Reiserfs API has been implemented which can allocate files without names but using their hash-index. This may speed up processes like squid, which have to store vast amount of files but don't care about their names. Cutting out the directory layer completely is a very nice sollution.
This is your sig. There are thousands more, but this one is yours.
The article at LinuxToday isn't about RedHat prefering ext3 over other journaling filesystems. It's merely an explaination of why they decided to include ext3 in the new RedHat 7.2.
The only comparison made is between ext3 and ext2 where they explain the advantages of a journaling system.
Linux has never crashed on me without a hardware problem causing it (not an exaggeration), but that doesn't mean we haven't had plenty of hardware problems, and each time there was a failure, the fsck would take 30-45 minutes. My first thought was ext3, but... heh. It was always grayed out in the kernel config menus. Not a good sign. ReiserFS on the other hand was immediately available.
Of course, you don't trust your data to something without being damn thorough about it, so I did a bunch of tests on staging servers (which went great) and I spent a lot of time reading Hans Reiser, who impressed me considerably as a smart person with a lot of good ideas. We made the move this spring and have had zero problems with the filesystem during normal operations. Zero. It's blazing fast on our tests, it appears to scale beautifully, and if I go down, I have no wait time anymore coming back up.
Of course, I keep up with the kernel changes and upgrade when I see updates relevant to the filesystem.
It's not a perfect package, but nearly. Its consistency checker/repair tool (reiserfsck) is not finished (as its messages vigorously warn). Now, remember, this is not the same thing as e2fsck. You are not using it in the same role, its purpose is much more specialized (disaster recovery), so the significance is different. Still; we came to use it during several of the many times high-speed SCSI chomped on our asses and corrupted data. We have backups, of course, but I wanted to see what the tool was capable of. In several cases it was able to successfully rebuild the filesystem, very slowly, with --rebuilddb, but in several other cases, the tool would dump core, which, if you were one of those fools without a backup, would leave you stranded.
Even in this, however, I was reassured; the maintainer of the tool answers emails quickly and was eager to try to troubleshoot the problem. I thus have no doubt that it will quickly mature into something quite good. It's just not there at this moment.
On the whole I would say I'm extremely happy with ReiserFS; we've punished it here pretty brutally and it's passed every test. I don't have any experience with ext3, but anecdotally I'm told it's less mature. Still, I have nothing against it. I can only comment that I hope Redhat's upgrade process from 7.1 to 7.2 will at least take reiserfs into account, instead of breaking the way it did from 7.0 to 7.1.
We're on the road to Tycho.
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?
http://cambuca.ldhs.cetuc.puc-rio.br/ has a install disk for RH & ReiserFS, I expect you could
use it for recovery.
These make nice emergency disks, including ssh:
http://www.lnx-bbc.org/ The LNX-BBC is a mini Linux-distribution, small enough to fit on a CD-ROM that has been cut, pressed, or molded to the size and shape of a business card.
Plato seems wrong to me today
I use Partition Magic on a regular basis to manage my partitions, resizing and moving them around as needed. (I know, it's commercial software, but it's one of the more useful pieces of commercial software out there, especially if you like to change things around a lot on your systems.)
PM supports ext2 but not any of the newer exotic journaling file systems like ReiserFS or xfs.
The fact that ext3 is comatable with ext2, and can be converted back and forth is a welcome feature for those who use PM to manage their partitions.
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
(Sorry if I be a little short-sentenced. I just wrote a whole story then Mozilla went nuts so now I am doing it again.)
;-), and that, as a result, journaling and devfs will really become mainstream when 2.5 is in good sight. So while 2.4 was supposed to bring us these two big features, in reality, well, it doesn't. Yes, I know, it provides the basis, is being worked on, can be obtained by patches etc. etc., but that doesn't practically make it much difference from 2.2, because as I said, for what I guess, most people still aren't encouraged to take the step to a journaling filesystem.
;-)
Two things: First, with 2.4 we were `promised' journaling and devfs. Both are still marked experimental, and of journaling, only ReiserFS is included as an appetizer, but the subsystem is still heavily in development. Some smaller things that were supposed to be improved at 2.4 are also still marked experimental. My guess is that most people -like me- are still using ext2 and device nodes, silently but eagerly waiting until journaling and devfs (and these other smaller things) get marked `stable' (by the proper authorities
Second: think GCC-2.96 (IIRC). RedHat has the power to shape the Free Software market a little bit the way they like it. With the inclusion of the compiler marked as GCC-2.96 they have practically released a GCC version without involving the GCC team. When RedHat issues a kernel that does ext3 (not just as an option, but as a default feature), I guess at least some of the results are the same as with the GCC-2.96 case. Although maybe this time not `faced with the facts' (that RedHat issued GCC-2.96), but merely `by popular demand' (from other distro's that want to use journaling by now), there will be some pressure on other distro's and the kernel developers to get journalining in.
Hmm. Maybe I'm really exaggerating the case. And do keep in mind that I'm not mad that I don't `get what I'm promised' or something like that. It just makes me nervous that I can't find ext3 anywhere in my fresh kernel sources (2.4.7; debian testing doesn't have 2.4.8 yet but I don't think the differences are that big wrt journaling and `marked experimental' stuff AFAIK from the changelogs) while the ext3 patches for the 2.2 series _are_ in the distro. And I really can use that stable VM of 2.4; earlier on the GIMP crashed my box, now it just crashes itself when loading huge things. I do get complete keyboard blocks once in a while, but no trashing anymore, and hey, that's what the reset button was built for, right?
Which brings us back to journaling.... Oh well
"We can confirm that Debian does *not* ship the version with the trojan horse. Our version predates it." [CA-2002-28]
I did not see any mention on the article on whether other journaling file systems would be available on Red Hat 7.2 as part of the installation/upgrade procedure.
We support installing to ext2 and ext3; reiserfs partitions are preserved when they're existing.
The kernel does not have XFS or JFS patched in (mostly code issues).
This message is provided under the terms outlined at http://www.bero.org/terms.html