JFS

Related articles
File systems
The
Journaled File System
(JFS) is a
journaling file system
that was open-sourced by IBM in 1999 and support for which has been available in the Linux kernel since 2002.
This article introduces the reader to the JFS file system. In particular, procedures for implementation, maintenance and optimization will be presented along with background information on the file system itself and some cautionary notes on precarious implementations.
Background
In 1990, JFS1, (then simply called JFS), was released for AIX version 3.1. The filesystem was closely tied to its targeted hardware, IBM's AIX line of UNIX servers, being a proprietary design.
In 1995, heavy development began on improving JFS, focusing on scalability and expanded features.
In 1997, parallel development began on moving the improved JFS source back to AIX.
In 1999, the improved JFS design was released for OS/2.
In 2001, the improved filesystem (newly termed JFS2), was released for AIX 5L.
The current GNU/Linux version is a port based on JFS for OS/2.
Note
While there are potential issues, JFS file systems for OS/2 and GNU/Linux are inter-operable.
[1]
.
While it is difficult to make general comparisons between JFS and other file systems available on UNIX and UNIX-like operating systems, it is claimed that JFS uses less CPU resources than other GNU/Linux file systems
[2]
. With certain optimizations, JFS has also been claimed to be faster for certain file operations, as compared to other GNU/Linux file systems (see
[3]
,
Benchmarks
).
GNU/Linux development team
The development of the GNU/Linux JFS port is headed by
Dave Kleikamp (dave dot kleikamp at oracle dot com)
HP:
https://jfs.sourceforge.net/
Technical features
JFS is a modern file system supporting many features, a few of which are listed here.
fully 64-bit.
dynamic space allocation for i-nodes, i.e. no running out of i-nodes on file systems with large number of small files.
Directory structures designed for speed and efficiency:
directories with eight or fewer entries have their contents storied inline within that directory's i-node.
directories with more than eight entries have their contents stored in a
B+ tree
keyed on name.
JFS utilizes extents for allocating blocks for large files.
Support for extended attributes in addition to standard Unix-style permissions.
Support for both internal and external logs (
see below
).
Extremely Scalable; Consistent performance from minimum file size up to 4 petabytes.
Algorithms designed for high performance on very large systems.
Performance tuned for GNU/Linux.
Designed from the ground up to provide Transaction/Log (not an add-on).
Restarts after a system failure < 1 sec.
Proven Journaling FS technology (10+ years in AIX).
Original design goals: Performance, Robustness, SMP.
Team members from the original AIX JFS Designed/Developed this file system.
Designed to operate on SMP hardware, with code optimized for at least a 4-way SMP machine.
TRIM support (since Kernel 3.7).
Note
JFS uses a journal to maintain consistency of metadata
only
. Thus, only consistency of metadata (and not actual file contents) can be assured in the case of improper shutdown. This is also the case for XFS and ReiserFS. Ext3, on the other hand, does support journaling of
both
metadata and data
[4]
, though with a significant performance penalty, and not by default.
A more comprehensive (and technical) overview of the features in JFS can be found in the
JFS Overview
authored by developer Steve Best.
Installation
The JFS driver is built as a module in the standard Arch kernel packages.
The
jfsutils
package must be
installed
to perform all file system related tasks.
Creation of a JFS file system can be done with the either:
# mkfs.jfs /dev/target_dev
or:
# jfs_mkfs /dev/target_dev
Both commands are equivalent.
Optimizations
The factual accuracy of this article or section is disputed.
Reason:
BFQ seems to work much better under load in 2021 (Discuss in
Talk:JFS#JFS Performance
)
There are several concepts that can be implemented with a JFS filesystem to boost its performance:
Periodic defragmentation of the file system.
Using the deadline I/O scheduler.
Utilizing an external journal.
Defragmenting JFS
JFS, like all file systems, will degrade in performance over time due to file fragmentation
[5]
. While there is in-place defragmentation code in the JFS utilities, this is code held over from the OS/2 port and has yet to be implemented
[6]
. For file systems that can be taken off-line for a time, one can execute a script like the following to defragment their JFS file system
Warning
This script is
dangerous
and may result in the wiping of an entire hard disk, if arguments get switched! Doing this type of operation is only recommended for people who have confidence in doing backups and file system operations.
umount /dev/hdc1
dd bs=4k if=/dev/hdc1 of=/dev/hdj1
jfs_fsck /dev/hdj1
mount -o ro /dev/hdj1 /fs/hdj1
jfs_mkfs /dev/hdc1
mount -o rw /dev/hdc1 /fs/hdc1
(cd /fs/hdj1 && tar -cS -b8 --one-file-system -f - .) | (cd /fs/hdc1 && tar -xS -b8 -p -f -)
umount /dev/hdj1
In this example,
/dev/hdc1
is the device with the data that needs backing up and
/dev/hdj1
is the device that holds the backup.
Basically, this script copies the data off the JFS file system to a backup drive, formats the original JFS file system and finally writes back the data from the backup to the freshly formatted drive in a way that JFS will write its allocation trees in a defragmentated way.
Warning
If a VMWare session is sitting on an underlying JFS partition that is highly fragmented, performance of the virtual machine may be significantly degraded.
Deadline I/O scheduler
JFS seems to perform better when the kernel has been configured to use the
Deadline I/O Scheduler
. Indeed, JFS's performance seems to exceed that of other GNU/Linux file systems with this particular scheduler being employed
[7]
.
External journal
Warning
As this is a relatively new feature to the GNU/Linux port of JFS, it is recommended to upgrade to the very latest version of jfsutils before attempting to implement an external journal (earlier versions seem to give errors when trying to create the journal device).
As with any journaled file system, a journal is constantly accessed in accordance with disk activity. Having the journal log on the same device as its corresponding file system thus can cause a degradation in I/O throughput. This degradation can be alleviated by putting the journal log on a separate device all together.
To make a journal device, first create a partition that is 128MB. Using a partition that is bigger than 128MB results in the excess being ignored, according to mkfs.jfs. You can either create an external log for an already-existing JFS file system by executing the following:
# mkfs.jfs -J journal_dev /dev/external_journal             # creates a journal on device /dev/external_journal
# mkfs.jfs -J device=/dev/external_journal /dev/jfs_device  # attaches the external journal to the existing file 
                                                          #   system on /dev/jfs_device
or a command can be issued to create both a new external journal and its corresponding JFS file system:
# mkfs.jfs -j /dev/external_journal /dev/jfs_device
This last command formats BOTH the external journal and the JFS file system.
Note
Obviously, an external journal is only effective if the journal and its file system exists on separate
physical
devices.
noatime fstab attribute
This article or section needs language, wiki syntax or style improvements. See
Help:Style
for reference.
Reason:
Duplicates
fstab#atime options
. (Discuss in
Talk:JFS
)
Every time a file is accessed (read or write) the default for most file systems is to append the metadata associated with that file with an updated access time. Thus, even read operations incur an overhead associated with a write to the file system. This can lead to a significant degradation in performance in some usage scenarios. Appending
noatime
to the fstab line for a JFS file system stops this action from happening. As access time is of little importance in most scenarios, this alteration has been widely touted as a fast and easy way to get a performance boost out of one's hardware. Even Linus Torvalds seems to be a proponent of this optimization
[8]
.
Note
One may also specify a
relatime
option which updates the atime if the previous atime is older than the mtime or ctime
[9]
. In terms of performance, this will not be as fast as the
noatime
mount option, but is useful if using applications that need to know when files were last read (like
mutt
).
Using the
noatime/relatime
option can improve disk performance with any file system, not just JFS.
Here is an example
/etc/fstab
entry with the
noatime
tag:
/dev/sdb1 /media/backup jfs rw,users,noauto,noatime 0  0
One may also mount a file system with the
noatime
attribute by invoking something similar to the following:
# mount -o noatime -t jfs /dev/jfs_dev /mnt/jfs_fs
Note
Access time is NOT the same as the
last-modified
time. Disabling access time will still enable you to see when files were last modified by a write operation.
Journal modes
JFS does not support various journal modes like
ext3
. Thus, passing the mount option
data=writeback
with
mount
or in
/etc/fstab
will have no effect on a JFS file system. JFS's current journaling mode is similar to Ext3's default journaling mode:
ordered
[10]
.
Variable block sizes
While the OS/2 port of JFS supports block sizes of 512, 1024, 2048, and 4096 bytes, the Linux port of JFS is only able to use 4k blocks. Even though code exists in JFS utilities that correspond to file systems using variable size blocks, this has yet to be implemented
[11]
. As larger block sizes tend to favor performance (smaller ones favor efficient space usage), implementing smaller block sizes for JFS in Linux has been given a low priority for implementation by JFS developers.
fsck and recovery
In the event that the file system does not get properly unmounted before being powered down, one will usually have to run
fsck
on a JFS file system in order to be able to remount it. This procedure usually only takes a few seconds, unless the log has been damaged. If running fsck returns an unrecognized file system error, try running
fsck.jfs
on the target device. Normally,
fsck
is all that is needed.
Cautionary notes
While JFS is very stable in its current stage of development, there are some cautionary notes on using this file system.
JFS root mounts read only on startup
Occasionally, a JFS root partition will be unable to mount in normal read-write mode. This is usually due to the fact that the JFS root file system fails its fsck after an unclean shutdown. It is rare that JFS fails out of fsck, and it is usually due to the JFS log itself being corrupted.
All that is required in this scenario is to boot your machine with a relatively recent Arch Linux LiveCD. Booting an Arch Linux livecd will give you access to all the JFS utilities and will load a kernel that is able to recognize JFS file systems. After booting the CD simply run
fsck
(or possibly
fsck.jfs
) on your JFS root and it should recover just fine (even though the fsck will probably take longer than normal due to the log probably being damaged). Once the
fsck
finishes, you should be able to boot your machine like normal.
Note
This scenario happens less than 10% of the time in the case of an improper shutdown.
JFS and secure deletions
Note
This section applies to any journaled file system, not just JFS.
The effectiveness of deleting files by overwriting their corresponding file system blocks with random data (i.e. using utilities like
shred
) can not be assured
[12]
. Given the design of journaled file systems, maintenance issues, and performance liabilities; reliable shredding of files as a deletion method does not sit highly on the priority list for implementation on any journaled file system.
Forced fsck on JFS root file system
One may force a
fsck
(
f
ile
s
ystem che
ck
) on the root file system by following
fsck#Forcing the check
and rebooting.
On Arch linux systems with a JFS root on a partition under control of
device-mapper
(i.e. the root device is a
lvm
or a LUKS encrypted one), forcing an
fsck
can sometimes remove the
/usr/man/man3/
directory. The reason for this issue is not clear, but the problem has been replicated
[13]
.
It is suggested to get a list of Arch Packages that use
/usr/man/man3/
by issuing a command similar to
# find /var/lib/pacman/local/ -name files | xargs grep -F "/man/man3/" | cut -d: -f1 | sort -u | awk -F/ '{print $6}' > man3_pkg_list
before attempting a forced
fsck
on a JFS root partition
[14]
. If
/usr/man/man3
does indeed disappear, simply reinstall all the packages listed in
man3_pkg_list
.
Note
If this problem does indeed happen, reinstalling all the packages using
/usr/man/man3/
does appear to fix the issue
[15]
.
As stated above, the reason for this issue is not clear at the moment; but it may have something to do with the fact that a forced
fsck
runs through higher phases of file system checks that only happen when a JFS log gets damaged in an improper dismounting of the partition.
JFS losing files
In JFS; journal writes are indefinitely postponed until there is another trigger such as memory pressure or an unmount operation. This infinite write delay limits reliability, as a crash can result in data loss even for data that was written minutes or hours before.
[16]
Benchmarks
As benchmarks measuring file system performance tend to be focused at specific types of disk usage, it is difficult to decipher good general comparisons rating how well JFS performs against other files systems. As mentioned before, it has been noted that JFS has a tendency to use less CPU resources than other GNU/Linux file systems and (with the right optimizations) is faster than other GNU/Linux file systems for certain types of file operations. It has been noted that JFS slows down when working with many files, however
[17]
[18]
. In the references are some links to benchmarks; but as always, it is best to test and see what works best for your own system and work load.
Conclusions
JFS is a stable, feature-rich file system that has not been publicized as much as some of the other Linux file systems. With optimizations, JFS is stable, CPU efficient and fast. In particular, VMWare sessions stand to benefit enormously from a properly optimized and defragmented, underlying JFS file system.
See also
A more technical
overview
of JFS
30 days with JFS
JFS
Sourceforge
page
Note on
defragmenting
JFS file systems
JFS Recovery
Sourceforge
page
Presentation
on JFS given by Steve Best (pdf)
Debian file system comparison
Wikipedia:JFS (file system)
Some
filesystem benchmarks