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