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."
I've been using ext3 ever since I upgraded to 2.4.14 a few days ago. Its nice to have the journaled FS... as I have been testing out a lot of !cough!nvidia!cough! proprietary drivers and bleeding edge software lately, and subsequently crashing. W/ ext3, I can get back to the crashing very quickly.
/var first, its simple to convert). It definitely speeds up the directory access... and on my squid it cut the average response time by a full half second... :-P.
That said, I also use ReiserFS for some other things(try
I personally think ext3 will win out, as it takes about 20 seconds to convert a 6GB partition... vs. XFS or ReiserFS taking nearly 10 minutes, and much more complexity.
SpamapS -- Undernet #Linuxhelp
Of course we'll have a lot of posts here talking about the issues of backwards compatiblity, ext3's offerings, etc, so we migh as well get those out of the way now.
From what I understand, ext3fs is just ext2 with journaling support, so in the (somewhat rare) event of a system crash you don't have to go through a time-consuming fsck during the next boot. Results in better data protection and more uptime.
If an ext3fs enabled kernel on an ext3 partition needs to go back to a previous kernel for some reason, or say, you forget to compile ext3 into a kernel, any ext2 kernel will still be able to read/write to an ext3 partition, as long as it was cleanly unmounted with the ext3 kernel.
Why not push ReiserFS, XFS, etc? It seems that most of these are not very well proven yet. ext2 is tried and true, kernel support is good, and the new revision adds journaling, so why not stick with ext3?
AFAIK, these are some of the most FAQs about ext3. I wonder how often they'll show up below...
XML is like violence. If it doesn't solve the problem, use more.
well the best part about ext3 is if something goes wrong .. you can convert the system back to ext2 in a second.. just mount it as ext2;-)
having said that .. i've been using ext3 for over a year now without any glitch. i had a 30G partition and lots of power failures .. so ext3 really eased my life and converting a current ext2 to ext3 is also pretty simple. no more backup of 30G of data ...
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.
Someone asked Linus about the preemptible kernel patches (and latency in general) at the Annual Linux Showcase on Thursday night. The thing about the preemptible kernel is that it is only for uniprocessor - SMP kernels aren't preemptible. So unless you want the SMP case to be capable of tying up a processor for "too long" at a time, then you need to re-do each bit of code which is capable of long latencies anyway. The other thing which came up is that responsiveness of the system improved quite a bit recently with VM fixes (2.4.14 was the improved version, I think). It was a matter of the VM queueing up too much I/O (and the drivers trying to throttle it, instead of just throttling it all in the VM - or something like that). The preemptible kernel won't solve that kind of problem - although it may change/mask the symptoms enough to make it a bit hard to be sure where a problem is.
Oh, and to bring things back to ext3, Steven Tweedie was also there and made a number of comments about ext3. He has been fairly busy/nervous lately as ext3 just got into the hands of Lots Of(TM) users (when it shipped with Red Hat 7.2). The most serious problem I remember him talking about was that the 7.2 installer had a box marked "upgrade my ext2 to ext3" and one marked "makefs the filesystem" (or something like that), and some people were checking both - which would create a nice new empty filesystem in place of the one which was being "upgraded". But of course that is just user error plus a confusing installer, not a kernel problem. Most of the things which looked like ext3 kernel problems seem to be something else, as far as Steven has been able to tell so far.
The ext2/ext3 limit is 4 terabytes, but Linux
device files have a 1 terabyte limit.
http://www.cs.uml.edu/~acahalan/linux/ext2.gif
Pay attention to the note on the right.
That explains why apps often break at 2 GB.
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.
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.
FreeBSD doesn't need a journaling file system: FreeBSD has softupdates, which ensure that the filesystem metadata is always in a consistent state while providing better performance than journaling.
Tarsnap: Online backups for the truly paranoid
It's like what's worse, dealing with a fscks that seems to take hours or increasing the risks of more crashes but at least you get back up faster. I can't live without quotas either. Can you imagine a student in a lab with a 10 Mbps connection to the Internet and a few hundred gigabytes of writable space? :)
It's starting to look like I can't have my cake and eat it too. :(
I'm glad Linus is blessing it. Hopefully the issues will be resolved soon. Until then, maybe redhat jumped the gun including it in their distro...
Heck if we can swap out the VM midstream, this is nothing :) Actually I think Linus was VERY smart to push the new VM into the kernel. Why? Because I believe he avoided a LOT of people running patched kernels until 2.5 was released. It was obvious the 2.4 VM was broken. Had he held off, folks would have realized (though probably slowly) that the new VM was better and they'd have patched it in anyway.
The same holds true for ext3. RedHat is already shipping it with RH 7.2. Its rock solid from their standpoint. So it makes sense to include it in the stable kernel. Sure, we all wish Linus had the ESP ability to have known to include these things at 2.4.0 (wait the new VM didn't exist then :) ) but given current circumstances, these are smart moves. Otherwise we'd all be patching kernels for another year to get ext3 (if we wanted it) and the new VM.
Yes, I realize patching kernels is a fact of life - I do it all the time to get XFS for my desktops and servers, but the less patches I need to worry about the better.
We can stick our noses in teh air and talk about how Linus never let big feature patches into the kernel before - well, everyone is allowed to change their mind. Besides, its not THAT huge a deal. If you're worried about stability, stick with what works. But if you need newer features for your setup, you can use a more recent stable kernel.
In the end, this ensures stuff in high demand sees production use earlier. If we waited to 2.6, you'd just be delaying it to far, not just for the new kernel development time, but also the 'I can't use 2.6.0 in a production box) so you'd wait until a later release. Just like you've waited to deploy 2.4.x production, right? :)
Things change. RIght now, I'd say for the bulk of the production systems, the smart move is to wait until Linus hands the kernel off for maintenance. Once that happens it'll see MUCH less churn. Befure we had 2 release stages... 2.x where x is odd for development, 2.even#.low# for release beta, and 2.even#.big# for stable production ready kernels I think thats a good thing. Besides its all relative - saying Linus shouldn't put x, y, z in the kernel because the last number is too high is pointless. We just need to adjust to the new release schedule!
I'm glad 2.4 has what it has. Now hopefully 2.6 will have XFS and I can run vanilla kernels again (nah - never gonna happen :) )
Top Most Bizarre/Disturbing Error Messages
Unfortunately, if your file system tools aren't upto date, your root partition won't be mounted ext3. A quick check to see if everything worked is to look at the output from either df or /proc/mounts like this;
In the second column, it should report the filesystem type of each mounted partition. If you don't see / , you should upgrade fileutils.
This is basically how your fstab is currently interpreted, as recorded in /etc/mtab.
If either of these look wrong, check the kernel sources for Documentation/Changes, and verify that you are using the supporting program versions mentioned in the Current Minimal Requirements section.
A firewall can not protect you from yourself. Turn off what you do not need. Do not use the firewall to do your work.
At the time Linus was staunchly against integrating video support into the kernel as a general device driver, even though an ongoing project called GGI (General Graphics Interface) had written a proof of concept video kernel module, supporting libraries, and an X server. Their system prevented these kinds of crashes by providing an abstraction API layer for applications to access the video hardware through the kernel, just as DRI does today, instead of having individual applications responsible for writing to the hardware directly. The argument then was that no userspace application should write directly to hardware considering the potential for race conditions, security problems, etc. And since all other hardware has an API layer through to the kernel, why not video?
This concept won out, but not the GGI project. Which is too bad because they had a good idea and a working system back in '96. I'm sure there were some politics involved, maybe a project lead at GGI pissed Linus off or something. I wasn't paying enough attention at the time.
Just a note about this in comparison with NT: the idea is to abstract out video acceleration routines into a hardware independent API for programmers. In NT 4.0 (which was current at the time), Microsoft placed not a video hardware acceleration API into kernel space, but much of GDI (their windowing system API). Many people thought this was unnecessary kernel bloat and complained vociferously about it being a prime cause of NT 4.0's instability. I'm not an NT programmer, nor do I know much about it's internals, so if anyone wishes to chime up and offer a better explanation please feel free.
One last point: now that DRI provides a direct kernel interface to video hardware, it's quite possible to take down an entire system with an errant DRI kernel module. Yup -- exactly the same kind of problem that linux advocates used to sneer at NT users over. The NVIDEA GForce proprietary DRI kernel modules are a prime example of problem drivers crashing people's systems. Ironic, huh?
Cheers,
--Maynard
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.