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

Comments

ext3, a journaled ext2 and not much more...

[SpamapS]

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.

That said, I also use ReiserFS for some other things(try /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.

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.

Re:ext3, a journaled ext2 and not much more...

[psamuels]

how come Office takes 20 full seconds to start up on my *4* GB system anyway?

Because you're not really converting the filesystem. The process consists of:

1. creating a journal file
2. marking it as a journal file in the various copies of your superblock

That's the beauty of ext3 - it is essentially ext2 with journaling, no more no less.

In fact, since this is the case, you can mount an ext3 filesystem as ext2 if you ever need to - the compatibility goes both forward and backward.

Some important points...

[ThatComputerGuy]

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

Re:Some important points...

[dbarclay10]

I'd just like to clarify some of this post's points:

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.

That's not entirely true for a couple of reasons; first of all, the ext3 code *started* as an exact duplicate of ext2, then they added journalling support. A lot has changed since then(in both code bases), so they're not identical any more. Secondly, journalling does not mean that there's no fsck; it just means that it's an order of magnitute or four faster. This is because during the filesystem consistency check, we know *exactly* where to look for problems(thanks to the journal). This doesn't result in better data protection, but it does result in better availability(and hence uptime).

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?

It should be noted that XFS has been around for years. I think your basic premise is still correct, though - neither XFS(in the scope of the Linux kernel) nor ReiserFS have been tested as extensively as ext3. And since ext3's code base started as ext2's code base, it doesn't even need so much checking.

Linus on preemptible kernel (and Tweedie on ext3)

[kingdon]

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.

ext2 limit graph

[Anonymous Coward]

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.

Re:FreeBSD

[cperciva]

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.

Tip: Root partition not being mounted ext3?

[Spoing]

If you're converting from ext2 to ext3, update /fstab so that 'auto' is used instead of either 'ext2' or(!)'ext3'. Auto makes it easy to dynamically switch to a kernel that doesn't support ext3.

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;

1. df -T

In the second column, it should report the filesystem type of each mounted partition. If you don't see / , you should upgrade fileutils.

1. cat /proc/mounts

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.