 |
|
|
Each of the three journaling file systems contained in Novell/SUSE
Linux Enterprise Server 8 (SLES 8) has its own set of features and
parameters. Some of the most important ones are mentioned here for
a quick overview.
A more complete description of file system characteristics can
be found in
http://www.osdl.org/docs/linux_journaling_filesystems_and_workloads.pdf.
|
EXT2 is the most widespread Linux file system used to
date. It offers no journaling features and was used in
the measurements for reference.
|
|
|
EXT3 evolved from EXT2 by adding journaling features.
It distinguishes between ordered, writeback metadata journaling
as well as full data journaling. In writeback mode, EXT3 commits
the changes to the file system in the order they are queued. In
ordered mode, EXT3 orders the changes and commits the metadata
changes first, then commits the data. “ordered” is the
EXT3 default mode.
EXT3 is currently the only file system on Linux on System z
offering full data journaling. In this mode not only file system
metadata but also all file system data are journaled.
The journaling mode is specified at mount time, e.g. “mount /dev/dasdd1 /data -o
data=writeback”.
Migration:
Another nice feature EXT3 offers is the seamless migration from
EXT2: just issue a “tune2fs -j
<partition>”. A journal is created and the file
system is mountable as EXT3. If you have hundreds of gigabytes of
data existing in EXT2 and you don't want to interrupt production,
backup, reformat and restore the data and EXT3 is available for
you.
Note:
EXT3 file systems may still be mounted as EXT2 after
migration.
Further information is available in a RedHat EXT3 whitepaper
(http://www.redhat.com/support/wpapers/redhat/ext3/)
and at Andrew Morton's homepage (http://www.zipworld.com.au/~akpm/linux/ext3/).
|
|
|
jfs is a port of OS/2 Warp Server jfs to Linux. It does not distinguish between
journaling modes yet. jfs journaling behaviour is comparable to the EXT3 order
mode. Compared to earlier versions of jfs the version included in SLES8 offers
the possibility to save the data and journal of the same file system to separate
disks. It is now also possible to increase the default journal size (0.4% of
aggregate size). Some of the features that other journaling file systems offer
are still in development. It is automatically included in SLES 8 service packs
and further information is available in at the jfs project homepage at http://jfs.sourceforge.net.
|
|
|
ReiserFS development is sponsored by Novell/SUSE, therefore it is the
default choice when installing SLES 8. ReiserFS journaling
behaviour is comparable to the EXT3 order mode. A patch for full
data journaling is available but not (yet) included in SLES 8.
Three performance tuning options (no unhashed relocation, hashed
relocation, no border allocation) are available for ReiserFS at
mount time. In addition, two options to modify the journal size and
the size of the journal transactions are available.
The latter could not be included in the measurement results, as
the creation of the file system failed due to a big-endian bug in
the ReiserFS code. This bug was fixed in SLES 8 SP2.
A nice feature ReiserFS offers is disk space optimization.
Although you may not profit from this when storing few very large
files, you will see the impact when storing a lot of small files
like you would on a mail or news server. This feature does have an
impact on CPU consumption.
Further information is available at the ReiserFS project
homepage (http://www.namesys.com/).
|
|
|
|
For comparison of journaling file systems contained in Novell/SUSE SLES
8, the well known benchmark dbench was used.
It simulates the (local) filesystem load that a NetBench run
against a samba server would create. The workload consists of a mix
of open, close, read, write, append and delete operations.
The first test series compares Linux journaling file systems in
an LPAR and under z/VM with 8 and 16 processes.
Most obvious, ReiserFS is the fastest of all journaling
filesystems. EXT3 is slightly behind reiser, whereas jfs is well
below all. VM numbers are slightly lower than LPAR numbers.
The second test series compares LVM and single disk setup for
Linux journaling file systems under z/VM.
Like in other experiments using LVM, all journaling file
systems also profit from a well chosen disk and LVM setup.
Throughput improvements range between 1.7 (ReiserFS, 8 processes)
and 3 times (jfs, 8 processes).
|
|
|
For EXT3 the writeback mode is slightly faster than ordered
(default), because there is no need to do transaction ordering.
Full data journaling increases the data integrity, but has a
significant impact on performance.
Running EXT3 with larger journal sizes offers slight throughput
improvements.
ReiserFS options only show minor throughput improvements. In
contrast, jfs optimizations show a major improvement when
increasing the journal size to 200MB.
|
|
|
Looking at the CPU load reveals an increased CPU consumption for
ReiserFS. A possible reason for this may be additional computations
done for disk space optimization.
|
|
- IBM eServer zSeries 900 (2064-216)
- IBM TotalStorage Enterprise Storage Server 2105-F20
- SLES 8 31 bit and 64 bit
- LPAR and z/VM 4.3.0
- Single disk and LVM
- Journaling filesystems EXT3 v0.9.18,jfs 1.0.24,ReiserFS
3.6.2
- Non-journaling filesystem EXT2 v0.5
- Used benchmark Dbench 1.2
|
|
|
|
|
