Latest revision as of 01:18, January 2, 2015

Ext3 in Action

Introduction

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.

Ext3 QuickStart

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

External Journals

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.

data=writeback Mode

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.

data=ordered Mode

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

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)

ext2

78

ReiserFS

67

ext3 data=ordered

93

ext3 data=writeback

74

ext3 data=journal

7

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!

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.