Slashdot Mirror
Ext3 Filesystem Explained
sheckard writes: "The next installment of the wonderful Advanced filesystem implementor's guide, part 7, details the ext3 filesystem in all of its glory. This is another great voyage into the world of journaling filesystems, and ext3 has been rock-solid in my experience."
ext3 catches my fancy because there's no ext2 --> ext3 conversion -- you just have to unmount, make a journal file, and remount. reiserfs migration is a challenge for the huge partitions.
And because there's only a journal as an addition, you can remount as ext2 after a clean unmount and everything will still work fine.
XML is like violence. If it doesn't solve the problem, use more.
2.4.15 should have it.
I've had an ext3 root partition for over a year - it needed a reboot to change root to ext3 in those days, though. All other partitions were done with a remount.
Now, any ext2 fs can be turned into ext3 by a single tune2fs command, with no remount and no reboot.
I'm sure you could come up with several benchmarks which show reiserfs to be faster than ext2/ext3/xfs/whatever, but for most desktops and servers, filesystem performance is not a factor to be overly concerned about - unless you choose something silly like umsdos or NFS over PPP. News servers and high load fileservers are a different matter of course.
Just had my first power-loss since switching to ext3 last night. Normally would take 10-15 minutes for my computer to restart after checking /home, etc. But today came up in just a couple of minutes with no corruption (or none I have noticed, or has been reported). So ext3 gets my thumbs-up!
According to the article you can freely convert back and forth between ext2 and ext3. So it follows that you could convert an ext3 back to an ext2, then resize the ext2 file system. Afterwards convert back to ext3. Not so tough.
Maybe it is possible to do it directly too, but the method I suggest will work in any case.
If your root partition is formatted as ReiserFS, you're pretty much limited. Try to make a partition big enough on your free space, and make an ext[2-3] there. Then copy everything that is on the root partition to the new ext* one (use "cp -pR" to preserve permissions). Try to reboot the system, passing 'root=/dev/hd??' to the kernel, being ?? the new ext partition. If everything boots fine, you're on your way. If not, you won't lose anything on your old ReiserFS root; just reboot as usual.
Linus' 2.4.14 already has it.
To summarize: yes, it's possible to resize ext3 partitions, so long as your resizer doesn't mind. Don't use Partition Magic to do it. It doesn't like it. Badly.
> extreme, perhaps? extendable? extraneous? extatic?
extended
Actually, Andrew Morton reckons ext3 is actually quicker than ext2 in spite of the journalling. Go figure. :)
--
Actually, the new journaling filesystems (ReiserFS, XFS, and JFS) are all *faster* than ext2. Also, journaling itself can cost very little these days because modern JFSs use large buffers and coalesce writes. For example, BFS achieves metadata performance nearly as high as ext2 on a heavily loaded system. So if all you're doing all day is creating/deleting/growing/shrinking files, the filesystem is only slightly slower. When you factor in all the performance improvements, it end up being faster.
A deep unwavering belief is a sure sign you're missing something...
XFS historically has very bad delete performance. I don't think its the fault of the journal, since other things involving the journal (growing or creating files) aren't slow (though, ReiserFS does seem to have the best journaling code). I don't know what the official take on this is, but here's my theory. Most filesystems use a bitmap to keep track of free blocks. XFS, on the other hand, uses a pair of B+ trees to mange extents of free areas. This allows it to find better (more contiguous) blocks more quickly when an allocation has to be done. A bitmap, on the other hand, has to do a scan through the bits and can't afford to spend a lot of time looking in different places for the "best" place to allocate. However, when deleting a file, the bitmap approach already has all the addresses of the blocks, so its just a matter of clearing some bits. XFS, on the other hand, has to go ahead an reinsert the blocks back into the B+ tree, which takes many more disk access and much more time. Normally, this is an okay tradeoff, since you usually grow files more often than you delete (ie. you grow it many times while writing it out to 2GB, but delete the thing in one go). On systems like Squid server, on the other hand, you create and delete files like mad, so Reiser is often faster in that case.
A deep unwavering belief is a sure sign you're missing something...
IIRC RH7.2 installs ext3 with both data and metadata logging enabled by default, so your performance change is most likely that you're doing two writes for every one you did before.