ext3fs in Linus' Kernel Tree

Hurray! by __david__ · 2001-11-09 19:05 · Score: 2, Interesting

I've been running with the ext3 patch for a couple months now and I really like it. There's nothing like locking up your system while testing some crazy hardware, and booting back up with no fsck... I'm glad its finally "blessed"!

Yay!

-David

--
There. Now go play some cool javascript games!

it's really simple by matrix0040 · 2001-11-09 19:27 · Score: 4, Interesting

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 ...

Those benchy thingies... by trilucid · 2001-11-09 19:30 · Score: 3, Interesting

Anybody have any real-world benchmarks we can have a look at? I hate to sound redundant on this, but performance is a big issue for web/file servers (which is mostly what I'm running these days).

If the "running the hell out of it" scenarios look good, I'll probably give it a shot on a production box. Actually, knowing me, I'll give it a shot anyhow, but hey... ;)

Just as a thought, I'm operating from a starting assumption that it's *pretty much* just ext2 with journaling, but it's the overhead for the journaling that raises my eyebrows just a tad...

Thanks for the feedback!

Re:Those benchy thingies... by Soft · 2001-11-09 22:38 · Score: 2, Interesting

I will now retest ext3, since I can't believe this result.

I wouldn't be too surprised; ext2 by default does completely asynchronous writes, while ext3 is more reasonable and flushes data to disk before transactions commit.
You may want to mount your ext3 partition with the data=writeback option, which is closer in behavior to ext2, or alternatively mounting your ext2 partition sync. But ext3 has not been thought for high performance, reiserfs probably fares better.
That said, I'm still using ext3 on my Linux boxes rather than reiserfs as the latter has a history of being unexportable by NFS (something to do with inode management). Now they say it's OK, but I'd have to look a bit deeper.

Is it light on HD requirements? by strredwolf · 2001-11-09 19:32 · Score: 3, Interesting

I'm on a laptop with a half-gig HD. No, I can't get a larger one because it's an old laptop and I don't have money to buy another. So far, I've crammed a decent install of Slack 8 with X11 onto it with about 150 Megs free on an ext2 partition.

Reizer leaves me with 100 free

Is this going to chew up more HD room? I'd love to find a nice, ext2-like file system to make this laptop's root.

--

--
# Canmephians for a better Linux Kernel
$Stalag99{"URL"}="http://stalag99.net";

Journalling for the unshaven masses? by Scooby+Snacks · 2001-11-09 19:55 · Score: 2, Interesting

Well, I don't know about that. I've been using ReiserFS since about 2.2.17 or 2.2.18, and it's worked great. It was officially integrated into the kernel in 2.4.1 (at the end of January this year), and distributions started incorporating it soon after. (Actually, before that, if I'm not mistaken. I was installing my work laptop last November, and the then-current version of SuSE supported creating ReiserFS partitions during the install even then. Wound up going back to Debian, though.)

So journalling's been available to the masses for a while now. Or maybe Michael meant ease of converting for the installed base?

Now if only the damn preemptible kernel patch would make it in. Unfortunately, it looks like that's going to wait until 2.4.5. *sigh*...

--

--
Runnin' around, robbin' banks all whacked on the Scooby Snacks...

ReiserFS kills interactive performance by Anonymous Coward · 2001-11-09 21:12 · Score: 2, Interesting

I've been using ReiserFS since about a month after it went into the standard 2.4 kernel tree, since I wanted a journalling filesystem. At first I just used it for /usr, and it worked great. There was a noticable performance increase accessing large directories (like /usr/share/doc), and it saved some space. A few months later I converted /home. It works OK normally, but when copying large files, the system becomes entirely unusable. The mouse pointer lags noticeably (it jumps across the screen in 100-pixel intervals), my 4-second XMMS buffer is emptied and my music stops playing, and the system load jumps to somewhere between 3 and 5. This is on a 1GHz P3, and DMA is on. I had the same problem on my 700MHz P3, with a different motherboard, but I never had these problems with ext2.

The problem is that writers starve readers on ReiserFS. When writing a lot of data (for example, copying an MP3 album or a movie), no processes will be able to read from that filesystem. It's a known problem in the ReiserFS FAQ, but they really downplay it's severity. If you regularly work with large files, or copy large groups of files (more than ~50MB), stay away from ReiserFS.

ext3 and quotas.... by weave · 2001-11-09 22:36 · Score: 4, Interesting

I'm trying to decide whether or not to convert a production system I manage that has 16,000 user accounts connected to a 1 terabyte EMC SAN. I've done a lot of searches and turned up some troubling posts about ext3 when it comes to using it with journaling and quotas turned on.

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...

Re:What? I didn't see any musos getting eaten by baptiste · 2001-11-09 23:55 · Score: 4, Interesting

how this wound up in a 2.4.* kernel instead of 2.5.*, where right now it really belongs,

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

Re:Ugh... More FUD From Within... by Lumpy · 2001-11-10 00:34 · Score: 4, Interesting

as a good example..

I have 1 linux box that is only accessable via Packet radio. It is currently about 250 feet in the air and about 35 miles away running on a 386 1/2baby motherboard (tiny mobo, almost a sbc too.) I installed in 1996 for the local ham radio group. It acts as a packet repeater/packet BBS and runs off of a Solid state IDE disk drive (A whopping 20 megabytes!!!)

It runs Kernel 1.2.5 from a reallly old yggdrasil distribution.

It hasn't been touched cince and has only rebooted because of power failures.

Linux is so horribly stable that it has worked flawlessly without attention for 6 years...

I dare anyone to show me a windows/dos/Xenix install that can do the same. Would you put it in a place that makes it basically impossible to get to without hiring someone at $290.00 an hour to bring it back down to you.

--
Do not look at laser with remaining good eye.

Get the right kernel config! by Anonymous Coward · 2001-11-10 01:39 · Score: 1, Interesting

Ah, but I've found that it's only if you enable agpgart with it... some form of conflict between NVdriver and the kernels agp drivers. With agpgart disabled q3 runs solidly as a rock...

History of kernel video drivers by maynard · 2001-11-10 01:40 · Score: 4, Interesting

Um, I was once told to (and subsequently did) install Linux on my main machine in 1996, when I was told that regardless of a bad video driver, the drivers themselves never enter protected memory space and shouldn't bring down the system. (I argued that the display drawer itself may crash, but no one seemed to agree with me).

Back then you were told right. In 1996 you were likely running a kernel 2.0 based distribution with Xfree86-3.x.x. At that time the XFree project wrote separate X servers for specific video chip set support with no integration into the kernel. Mind you, the X server still ran SUID as root, and had control of the console, so a crash might not take down the entire system (networking, disk, and VM would still be up), but the net result could be a hosed console requiring a reboot anyway.

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 can attest to that by Ender+Ryan · 2001-11-10 02:12 · Score: 3, Interesting

The stability of ext2 I mean.

I have a tiny box at my home that I use as a router. It's a couple years old now. The box itself is a P100 with all the guts inside loose and hanging all over the place. The HD is > 5 years old and is loud and very unstable, simply doesn't turn on sometimes.

This little machine stays up 24x7 and only goes down when the power goes out, which is at least once a week here. After a power failure, the drive usually doesn't turn back on until the machine is power cycled and sometimes the whole machine will not turn on... and sometimes requires a light smack ; )

Even though this little box is a piece of dying crud, after it powers up properly it fscks and boots linux in about 1 minute and works every time. It has NEVER failed to boot after powering up properly after years of constant use. This Linux install is years old, running an older 2.2 kernel and has required absolutely 0 maintenance, other than smacking the machine to get it to power on ; )

At work we have... haven't counted in a while... say 20 odd machines. About half of them are servers running Linux and 1 BSD box, which do not require any routine maintenance. The other half are running W2k and require constant maintenance. Even if Windows was free, for our small company the TCO would STILL probably be about 3 times that of Linux or BSD. It is simply unacceptable how much time and energy we've had to put into fixing NT and W2k boxes.

Of course, no matter what anyone here says, there will still be people who adamantly claim that NT/2k/XP require less maintenance and have a lower TCO than Linux/BSD and many will claim that the ease of use of windows is extremely important. That is simply false, as if one isn't skilled enough to setup a Linux/BSD box, they're going to be one of the people who's boxes get infected with all the "microsoft worms" that spread around...

--
Sticking feathers up your butt does not make you a chicken - Tyler Durden

ext3 needed in main tree now by walt-sjc · 2001-11-10 04:27 · Score: 3, Interesting

I believe Linus has learned to be a little more realistic with releases. While publicly he states that he doesn't care a hoot about what any polls, groups, or the press want or think, and is only interested in building the best dang kernel, my guess is that he desires to see Linux really catch on in the corporate world (and I'm talking linux vs other unix - not displacing MS.)
The corporate world really wants to see business features in the production kernel such as a rock solid good performing VM, a journaling file system, etc. The older kernels' VM and lack of journalling were really singled out as being critical hurdles for corporate acceptance.

It didn't matter that RedHat had ext3 or ReiserFS, it was needed in the base kernel without messing around with patches. It's more of a mindset / perception thing than reality.

The fact is, the corporate world wasn't going to wait another 2 years for 2.6. Those features really needed to be mainstream now. The only thing I'd really like to see added are extended ACLs, but that can wait. I don't know if a solution to device numbering can if Linus won't assign new numbers... (Alan will however, in his tree...)

Thanks Linus! And a big thanks to all the hundreds of other kernel hackers that made this all possible!

14 of 384 comments (clear)