Slashdot Mirror
ext3fs in Linus' Kernel Tree
peloy writes: "According to Linus' changelog for Linux 2.4.15pre2, the long waited ext3fs, the sucessor of ext2 with jounaling capabilities, has finally made its way into the official kernel tree. I have never tried ext3fs but it looks that now that it is "blessed" by Linus I'll be upgrading my old and trusty ext2fs partitions soon."
http://ftp.sourceforge.net/ has 850GB storage, half of which is reiserfs, half is ext2. Both filesystems have been running flawlessly for > 4 months of production (actually longer, but wasn't reiserfs before). That server pushes between 15Mbit and 50Mbit/sec, and pulls/syncs about 2-5Mbit/sec, 24x7. reiserfs also powers the CVS tree filesystem for cvs-mirror.mozilla.org (also tokyojoe.sourceforge.net), which is the one and only anonymous CVS checkout point for mozilla. That server has run flawlessly under very heavy load since its birth. I don't get involved in kernel politics, but as a production filesystem, reiserfs is ok in my book.
First, XFS is not necessarily a proven technology. XFS is a port of the XFS filesystem used on IRIX systems. XFS has a proven history of performance and stability, but that is on IRIX. The Linux version of XFS will be proven technology when that version proves it to the Linux community.
Why choose ext3? Ext3 is an extension of ext2. The XFS code adds many changes to various parts of the Linux kernel. Ext3, changes less. XFS changes must wait for the 2.5 tree.
In the long run, I think ext3 will win out above, ReiserFS, XFS, and JFS. Being able to convert and ext2 to ext3 partition is the largest advantage. I know I didn't want to do a backup-restore to convert a partition. Within seconds, you can convert ext2 to ext3.
"I did mkreiserfs on a 40gig drive and it took seconds." Yeah, creating the FS takes seconds. But if you have a filesystem you want to convert, it takes much longer and some strategy, too. Where ext3 only needs a few seconds for the creation of the journal. On my system it also require the partition to be unmounted, which is difficult for the root. But apparently, it's only on *MY* system :)
Okay, if you have a set A with N elements, and you add an element to the set such that set A now has N+1 elements... well, that doesn't change the original 0 through N elements.
Your complaint can be applied to the case of adding driver support to an existing kernel. You see, in the life of a kernel, time passes. As time passes, new hardware, software, algorithms, etc. come out. In order for us to keep modern, we have to add new things to the existing set. You're just... silly.
Going back to my original statement, the new virtual memory subsystem wasn't an addition. He was removing an element from the set and replacing it with something different. That could be argued as bad, but in practical terms it ended up perfectly fine.
Furthermore, if you had done any homework, you'd have realized that ext3 is built using hooks that have been available in ext2 for years. Technically speaking, ext3 is as stable as ext2 because the fs can still function as ext2 if ext3 support goes away or breaks.
So stop bitching about support for new things being added to the kernel. We could only be lucky if new features were added faster. At the very least, stop dumping FUD on us. Your alias is so very appropriate in light of your post.
Why bother.
Think of ext3 as "only a driver" -- which in your book is OK for a stable kernel. In terms of how much the code disturbs the rest of the kernel if you don't compile it in -- it really doesn't, just like a driver.
The VM change in 2.4.10 -- there I agree with you. (As does Linus, apparently, as he later admitted.)
"How can you claim that you are anti-crack, while still writing a window manager?" — Metacity README
An important factor in Linux' cost is its maintenance. Linux requires a *lot* of maintenance, work doable only by the relatively few high-paid Linux administrators that put themselves - of course willingly - at a great place in the market. Linux seems to be needing maintenance continuously, to keep it from breaking down.
/dev/hda4 is easier to understand than /dev/ct0s1r4? Also, you're saying that the typical utilities are unreliable? Where's your support? Notice many commercial Unixes (not "Unices"... Unicos is Cray's OS) are moving to GNU utilities? Ugh... this complaint is so unsubstantiated I can't even level a structured retort!
You're off your rocker. Linux boxes have to be admin'ed ONCE in a big way, then they just keep working after that. You've mistaken it for NT, which BREAKS constantly and requires constant attention. I have a Linux server sitting in my closet that I haven't touched for months. It just works and gets heavy use. Not to mention that when used properly, *nix solutions have a constant maintenance cost, while NT solutions require growing fees. What do I mean? With *nix, you have one central box that needs adminning, and all your clients get their apps, configuration, and data from that box. So, if you have N machines, you have 1 box to admin. With NT, every seat has to have its own apps, data, and configuration. You multiply your work load by a factor of N. So, if it costs C dollars to admin one machine, NT costs C*N, while properly implimented *nix solutions are C.
Add to this the cost of loss of data. Linux' native file system, EXT2FS, is known to lose data like a firehose spouts water when the file system isn't unmounted properly. Other unix file systems are much more tolerant towards unexpected crashes. An example is the FreeBSD file system, which with soft updates enabled, performance-wise blows EXT2FS out of the water, and doesn't have the negative drawback of extreme data loss in case of a system breakdown.
More nonsense. ext2 will lose data if the data isn't written to the disk when a failure occurrs. So will UFS. But you won't experience corruption of data you're not working with otherwise. ext2 is stable and solid. It gets corrupted if you fuck with it. Same goes for every other fs.
According to Linux advocates, an alternative to EXT2FS would be ReiserFS. Unfortunately, ReiserFS is still in beta stage. This means it is not intended for production use (although according to many Linux advocates this shouldn't be a problem, which makes me wonder how (little) valuable they find your data).
ReiserFS isn't in beta. It's sufficiently stable and is used by lots of people on production machines.
The other proposed 'solution', EXT3FS, is nothing more than an ugly hack to put journaling into the file system. All the drawbacks of the ancient EXT2FS file system remain in EXT3FS, for the sake of 'forward- and backward compatibility'. This is interesting, considering that the DOS heritage in the Windows 9x/ME series was considered a very bad thing by the Linux community, even though it provided what could be called one of the best examples of compatibility, ever. When it's about Linux, compatibility constraints don't seem to be that much of a problem for Linux advocates.
Uh, no. Backwards compatability is good if the older stuff is still used. Also, the backwards compatability in ext3 does not break its implimentation. DOS is dead and burried. There was no reason to keep support for it lying around, but MS did anyway and it was responsible for a LOT of the instability in Windows 9x/2000. People still using DOS stuff, should not be upgrading. Microsoft just forces them to. Not only that, ext[123] was designed to be EXTENSIBLE, something Microsoft idiots don't seem to understand. Extensiblility is about being able to add future functionality without rewriting or breaking a package. Hooks exist in ext that let you add new features. This is a Good Thing.
Back to Linux' cost. Factor in also the fact that crashes happen much more often on Linux than on other unices. On other unices, crashes usually are caused by external sources like power outages. Crashes in Linux are a regular thing, and nobody seems to know what causes them, internally. Linux advocates try to hide this fact by denying crashes ever happen. Instead, they have frequent "hardware problems".
I'd like to see some statistics. This claim is unsubstantiated. I've seen Solaris boxses drop like flies. However, most Linux boxen I've ever used have been VERY stable and once everythings up and running, it flies smooth for months even years at a time. If "Linux" crashes (what you think is Linux crashing, is actually XFree86 or Mozilla), it's usually recoverable. Don't confuse your lack of knowledge with Linux being unstable.
The steep learning curve compared to about any other operating system out there is a major factor in Linux' cost. The system is a mix of features from all kinds of unices, but not one of them is implemented right. A Linux user has to live with badly coded tools which have low performance, mangle data seemingly at random and are not in line with their specification. On top of that a lot of them spit out the most childish and unprofessional messages, indicating that they were created by 14-year olds with too much time, no talent and a bad attitude.
This is pathetic. Linux makes things at the system level easier for most users to understand. You're saying that, say,
I could go on and on and on, but the conclusion is clear. Linux is not an option for any one who seeks a professional OS with high performance, scalability, stability, adherence to standards, etc.
You're right. Windows is much more stable and reliable. Oh yeah, and Solaris is much cheaper and secure. Forget free software. It sucks. I mean, it's worthless, because it's free, right? I mean, why would it be free if it was good? Anything that's good is worth paying millions for.
You're so hopelessly confused that I can't tell if you're a Windows luser/wadmin or a pro-BSD zealot that doesn't even use BSD but read about the fights between the two camps. Maybe I'm juts feeding a troll here, but I gotta battle the FUD.
Why bother.
Wow, you know, when choosing the best solution I always go by the most useless criteria. Geez, do you really care whether it takes you 10 seconds or 10 hours to convert a filesystem? There are more important things to consider, the actual conversion is the least of your worries.
If the kernel crashes, it is not reasonable to assume that the journaling code worked correctly after the bug occured somewhere in the kernel. After all, random kernel memory could have been overwritten. If the kernel data structures are no longer intact, the kernel (including file system journaling) can no longer work reliably.
no more backup of 30G of data
I'm hoping by this comment that you're not the same user who's Ask Slashdot just got posted, asking how to become a UNIX admin, cuz this ain't it. It's funny that you should pick that exact number too, because a close friend of mine was shifting disks around in his systems yesterday. At some point he lost track of exactly which hard drive was connected to which ribbon and which IDE port that ribbon was connected to. He ended up running a fresh install of RH7.2 over the 30GB hard drive to which he had "backed up" everything he has collected over the last five years. He called me saying he felt like he was going to throw up.
I say "backed up" because, as an enterprise systems architect, I don't believe anything is a backup unless it takes at least a little effort to destroy the data. You can't throw a write protect tab on a hard drive. When I traded a P75 system for a 10GB hard drive with the friend above, he gave it to me with over 5GB's of his stuff on it. I backed it up to tape with Amanda, and write-protected the tape. I never thought *he* would need me to restore his data off my tape.
Intelligent Life on Earth
I don't judge a filesystem based on what kind of tools are there to 'convert' it from something else. That's not what it's designed for, and has nothing to do with what you get out of it.
No kidding ext2 takes seconds to convert to ext3... it's the same filesystem.
well if at any point, the kernel simply locks cold and doesn't do anything, the journaling will work fine since it's prepared for the case of a power outage. If the kernel gets corrupted in some odd way but doesn't write to the disk again, the journal will also be fine. You are right that filesystem integrity could be damaged by a corrupted kernel that continued to operate; it would also be possible for such a beast to install Windows XP on all its filesystems, since in that case we are by definition in an undefined condition. I think it's generally unlikely for such a thing to happen, but it's certainly possible and it's happened before (well, maybe not the Windows XP part...)
I have seen the future, and it is inconvenient.