Slashdot Mirror
Why Redhat Choose ext3 For 7.2
mz001b writes "There is an interesting article from RH posted on LinuxToday discussing why they chose ext3 over the other available journaling filesystems (ReiserFS, xfs, jfs,...) for RH 7.2"
← Back to Stories (view on slashdot.org)
You are missing a little from your math. Alan Cox is not relevant in this case.
Stephen Tweedie is. He is one of the top filesystem ext[23] hackers and is employed by Redhat. RedHat runs the mailing list for ext2 and ext3 stuff.
But mostly, ext3 allows new filesystems to be employed over old existing ones without a backup and re-creation of the file system. This means ext3 will be deployed (in the US) 10 times more than any other journaled file system.
As for speed, I think the ext[23] file systems, which are already fast, are going to catch up with the addition of an inode hash from Daniel Phillips. Or with his Tux2 file system which is in development. But really, unless you use directories with a large number of small files, ext2 and ReiserFS are not much different for speed.
Having an EASY upgrade path is the way. I also suspect Linus will add ext3 to the mainline kernels in another 2-3 kernel iterations, since the ext3 hackers are quite used to the appropriate methods for getting new code included.
... since Alan Cox (@redhat.com) had so many arguments over the Linux kernel Mailing List with Hans Reiser.
This thread is a good example.
Reiser performs better than ext2 mainly on two points:
ext2 uses a linear search algorithm to index directories while Reiser uses a hashtable. This makes handing of large (10000+ files) directories far more efficient. No more need for /home/h/he/hensema.
Reiserfs also packs together the 'tails' of files, meaning that multiple endings of files can occupy the same disk block. This saves space (less slack). The classic example where this works very well is a newsspool, containing hunderds of thousands of files sized typically around 4 KB.
I'm not sure wether the special Reiserfs API has been implemented which can allocate files without names but using their hash-index. This may speed up processes like squid, which have to store vast amount of files but don't care about their names. Cutting out the directory layer completely is a very nice sollution.
This is your sig. There are thousands more, but this one is yours.
The article at LinuxToday isn't about RedHat prefering ext3 over other journaling filesystems. It's merely an explaination of why they decided to include ext3 in the new RedHat 7.2.
The only comparison made is between ext3 and ext2 where they explain the advantages of a journaling system.
http://cambuca.ldhs.cetuc.puc-rio.br/ has a install disk for RH & ReiserFS, I expect you could
use it for recovery.
These make nice emergency disks, including ssh:
http://www.lnx-bbc.org/ The LNX-BBC is a mini Linux-distribution, small enough to fit on a CD-ROM that has been cut, pressed, or molded to the size and shape of a business card.
Plato seems wrong to me today
It's just as easy to resize with GPL'ed tools. I've had times where Partition Magic is not avaliable to me, and I needed to resize a partition. I loaded up a boot disk with a copy of resize2fs and away it went.
resize_reiserfs works much in the same way.
I'm honestly not sure if the metadata and journal will be fully compatable with Partition Magic. It may just lead to a corrupt partition, but hell, that's what backups are for.
I did not see any mention on the article on whether other journaling file systems would be available on Red Hat 7.2 as part of the installation/upgrade procedure.
We support installing to ext2 and ext3; reiserfs partitions are preserved when they're existing.
The kernel does not have XFS or JFS patched in (mostly code issues).
This message is provided under the terms outlined at http://www.bero.org/terms.html
That's not strictly true. The ext3 filesystem makes sure transactions are atomic; that is, you never end up with a half-written file. Either the write will complete cleanly, or the write will be treated like it never started. It does this by writing (in "journal=ordered" mode) all the new data to a different part of the disk, before committing the journal, which allows updating of the file's metadata and the freeing of the old blocks.
So you may "lose" a write, but it shouldn't mean that you have corrupted data. With ext2 and other traditional fsck filesystems, you actually can end up with a file that's half old data and half new data after a bad disk crash and fsck.