Funtoo Filesystem Guide, Part 5
Ext3 in Action
Back around 2002, when this article was originally written, Andrew Morton had a nice little introduction to using ext3 on his Web site. His site has since disappeared, so in this updated article, I'll summarize Andrew Morton's original documentation. Then, in the second half of the article, we'll delve into some meatier ext3 topics, ones that I think you'll find very useful.
(Not) Patching the Kernel
These days, there is no need to patch your kernel for ext3. Ext3 has been incorporated into the Linux kernel for a long time, and is very mature.
Converting ext2 to ext3
One of the nice things about ext3 is that you can easily convert an ext2 filesystem to be an ext3 filesystem. All that you need to do is to create a journal on the ext2 filesystem, as follows:
tune2fs -j /dev/sdXX
You can even do this while the filesystem is mounted. If it is currently mounted, it will not function as an ext3 filesystem until you are able to remount it as ext3. Remember to update /etc/fstab to so that it refers to the new filesystem as an ext3 filesystem.
Creating New Ext3 Filesystems
Simply use the -j option with mke2fs, as follows:
mke2fs -j /dev/sdXX
Switching Between Ext2 and Ext3
It is possible to mount an ext3 filesystem as an ext2 filesystem, as long as the ext3 filesystem has been cleanly unmounted. Simply specify a filesystem type of ext2 when mounting an ext3 filesystem with older kernels. You can also specify a filesystem type of auto in /etc/fstab, which will tell the mount and fsck commands to utilize the filesystem as ext3 if such support is available, otherwise falling back to ext2.
Fixing Dirty Ext3 Filesystems
If your ext3 filesystem was not cleanly unmounted, then you should be able clean it up using e2fsck as follows:
e2fsck -fy /dev/sdXX
The filesystem should now be mountable as ext2.
Ext3 Root Filesystem Tricks
If you want to force a Linux kernel to mount an ext3 filesystem as an ext2 filesystem, add the rootfstype=ext2 kernel boot parameter to the kernel boot parameters in lilo.conf or grub.conf.
To tell the Linux kernel to mount your root ext3 filesystem using a particular journaling mode, use the rootflags kernel boot parameter as follows (using a grub.conf example):
kernel /boot/bzImage rootflags=data=journal root=/dev/sda3
Filesystem Check Intervals
By default, e2fsck will perform an exhaustive filesystem check every now and then, even if the filesystem was cleanly unmounted. By default, this happens every twentieth mount or every 180 days, whichever comes first.
While this might have been handy for ext2 filesystems, it's not optimal for ext3. To turn this automatic exhaustive filesystem check off, use the following tune2fs command:
tune2fs -i 0 -c 0 /dev/sdXX
You can view the filesystem check interval (as well as lots of other interesting information) by typing tune2fs -l /dev/sdXX.
Ext3 supports the ability to place the journal on a separate persistent device. To create an external journal on /dev/sdb, type:
mke2fs -O journal_dev /dev/sdb
Then, to create an ext3 filesystem on /dev/sda3 that uses this external journal, type:
mke2fs -J device=/dev/sdb /dev/sda3 mount /dev/sda3 /mnt/test -t ext3
Ext3 Journaling Options and Write Latency
Ext3 allows you to choose from one of three data journaling modes at filesystem mount time: data=writeback, data=ordered, and data=journal.
To specify a journal mode, you can add the appropriate string (data=journal, for example) to the options section of your /etc/fstab, or specify the -o data=journal command-line option when calling mount directly.
As we covered earlier in this article, if you'd like to specify the data journaling method used for your root filesystem (data=ordered is the default), you can to use a special kernel boot option called rootflags. So, if you'd like to put your root filesystem into full data journaling mode, add rootflags=data=journal to your kernel boot options.
In data=writeback mode, ext3 doesn't do any form of data journaling at all, providing you with similar journaling found in the XFS, JFS, and ReiserFS filesystems -- metadata only. As I explained in my previous article, this could allow recently modified files to become corrupted in the event of an unexpected reboot. Despite this drawback, data=writeback mode should give you the best ext3 performance under most conditions.
In data=ordered mode, ext3 only officially journals metadata, but it logically groups metadata and data blocks into a single unit called atransaction. When it's time to write the new metadata out to disk, the associated data blocks are written first. data=ordered mode effectively solves the corruption problem found in data=writeback mode and most other journaled filesystems, and it does so without requiring fulldata journaling. In general, data=ordered ext3 filesystems performslightly slower than data=writeback filesystems, but significantly faster than their full data journaling counterparts.When appending data to files, data=ordered mode provides all of the integrity guarantees offered by ext3's full data journaling mode. However, ifpart of a file is being overwritten and the system crashes, it's possible that the region being written will contain a combination of original blocks interspersed with updated blocks. This is because data=ordered provides no guarantees as to which blocks are overwritten first, so you can't assume that just because overwritten block x was updated, that overwrittenblock x-1 was updated as well. Instead, data=ordered leaves the writeordering up to the hard drive's write cache. In general, this limitation doesn't end up negatively impacting people very often, since file appends are generally much more common than file overwrites. For this reason,data=ordered mode is a good higher-performance replacement for fulldata journaling.
data=journal mode provides full data and metadata journaling. All new data is written to the journal first, and then to its final location. In the event of a crash, the journal can be replayed, bringing both data and metadata into a consistent state.
Theoretically, data=journal mode is the slowest journaling mode of all, since data gets written to disk twice rather than once. However, it turns out that in certain situations, data=journal mode can be blazingly fast. Andrew Morton, after hearing reports on LKML that ext3 data=journal filesystems were giving people unbelievably greatinteractive filesystem performance, decided to put together a little test. First, he created simple shell script designed to write data to a test filesystem as quickly as possible:
while true do dd if=/dev/zero of=largefile bs=16384 count=131072 done
While data was being written to the test filesystem, he attempted to read 16MB of data from another ext2 filesystem on the same disk, timing the results:
# time cat 16-meg-file > /dev/null
The results were astounding. data=journal mode allowed the 16 MB file to be read from 9 to over 13 times faster than other ext3 modes, ReiserFS, and even ext2 (which has no journaling overhead):
|Filesystem||16 MB read time (seconds)|
Andrew repeated this test, but tried to read a 16 MB file from the test filesystem (rather than a different filesystem), and he got identical results. So, what does this mean? Somehow, ext3's data=journal mode is incredibly well-suited to situations where data needs to be read from and written to disk at the same time. Therefore, ext3's data=journal mode, which was assumed to be the slowest of all ext3 modes in nearly all conditions, actually turns out to have a major performance advantage in busy environments where interactive IO performance needs to be maximized. Maybe data=journal mode isn't so sluggish after all!
Andrew is still trying to figure out exactly why data=journal mode is doing so much better than everything else. When he does, he may be able to add the necessary tweaks to the rest of ext3 so that data=writeback and data=ordered modes see some benefit as well.
I hope to see you soon when I release the next installment in the Funtoo Filesystem Guide!
Be sure to checkout the other articles in this series:
Daniel Robbins is best known as the creator of Gentoo Linux and author of many IBM developerWorks articles about Linux. Daniel currently serves as Benevolent Dictator for Life (BDFL) of Funtoo Linux. Funtoo Linux is a Gentoo-based distribution and continuation of Daniel's original Gentoo vision.
Keychain 2.8.2 ReleasedKeychain 2.8.2, a maintenance and bug fix release, is now available.
Unfork Tree is Live!The "unfork" tree is now merged into the main Funtoo Linux tree, and Funtoo Linux is now using shards for core packages, x11 (including media libraries), KDE, GNOME, python and perl.
Browse all our Linux-related articles, below:
- Funtoo Filesystem Guide, Part 1
- Funtoo Filesystem Guide, Part 2
- Funtoo Filesystem Guide, Part 3
- Funtoo Filesystem Guide, Part 4
- Funtoo Filesystem Guide, Part 5
- Learning Linux LVM, Part 1
- Learning Linux LVM, Part 2
- Linux Fundamentals, Part 1
- Linux Fundamentals, Part 1/pt-br
- Linux Fundamentals, Part 2
- Linux Fundamentals, Part 3
- Linux Fundamentals, Part 4
- LVM Fun
- Making the Distribution, Part 1
- Making the Distribution, Part 2
- Making the Distribution, Part 3
- Maximum Swappage
- Partition Planning Tips
- Partitioning in Action, Part 1
- Partitioning in Action, Part 2
- POSIX Threads Explained, Part 1
- POSIX Threads Explained, Part 2
- POSIX Threads Explained, Part 3
- Prompt Magic
- The Gentoo.org Redesign, Part 1
- The Gentoo.org Redesign, Part 2
- The Gentoo.org Redesign, Part 3
- The Gentoo.org Redesign, Part 4
- Traffic Control