The Journaling File System: A Brief Overview for a Linux Novice

The freedom of choice is apparently the hallmark of all open-source technologies like Linux, so if you opt to put your computing life into its space, choosing a Linux distro is just the first step you need to take. Though all of them have a default file system, there are still a bunch of worthy alternatives to the “big names” like ext or ZFS. One of them is the Journaling File System (JFS), which is, despite being not as widely used as its counterparts, has its own distinctive features that may appear to be beneficial in your specific case. Thus, it probably won’t hurt for any Linux user to have at least basic knowledge of its internals and main characteristics.

Surprisingly, JFS was developed by IBM in the mid-90s as the standard file system for their AIX line of Unix servers. In 1999, it was donated to open-source and since 2002 has become available as a part of the Linux kernel. In spite of its pedigree, JFS failed to acquire ubiquity in the Linux world. Whilst most distributions, like Fedora, SUSE, Slackware, Debian and Ubuntu, do support JFS, all of them use ext by default. However, being very lightweight, fast and efficient, this file system performs well under a big variety of situations.


The whole space in JFS is divided into logical blocks 4096 bytes each (this is the default value, but you can specify a smaller block size: 2048,1024 or even 512 bytes). The first logical block is called superblock and keeps all essential information about the file system. The remaining room is split up into allocation groups, each containing inodes and data blocks.

Each file in JFS is stored in extents, which are sequences of contiguous data blocks (normally, an extent is kept within a single allocation group, but very large ones may span multiple allocation groups), and is represented by its own inode providing all metadata about this file such as its type, permissions etc. An inode of a file also records the addresses of the extents where its actual contents are stored. Such an address consists of the starting block and the length of the extent in blocks, and all of them form a structure called a B+ tree (if you are not familiar with B+ trees, this is just a tree structure in which each node contains an ordered list of keys and pointers to the nodes at the lower level in the tree).

The space for inodes is allocated dynamically and gets released when it is no longer needed. Thus, JFS won’t run out of inodes when a large number of small files is stored, unlike some other file systems in which you need specify the number of inodes in advance. Among other perks of using JFS are:



Thanks to logging all metadata operations in a special file called journal, JFS can guarantee fast recovery after system crashes. Moreover, instead of writing multiple journal entries for simultaneous changes to the file system, JFS combines them into a single mass commit, thus significantly reducing performance decrease due to multiple writes.


Efficient organization of directories

The contents of small directories are stored directly in their inodes, while for larger ones B+ trees are employed instead of traditional linear structures, which provide for their fast retrieval.


Efficient use of storage space and CPU recourses 

JFS stores files in extents instead of separate data blocks, ensuring that they are allocated as contiguously as possible, even when a file grows in size. As all extents are indexed in B+trees, they can be easily located and new ones can be quickly inserted when needed. All this results in notably improved performance.



JFS is a fully 64-bit file system. The maximum supported size of a JFS-formatted volume is 4 petabytes (if you use the default block size of 4 KB), while separate files can be up to 16 terabytes. The number of files that can be created is limited only by the amount of free space in the file system.


Support for sparse files

When the file system you use doesn’t support sparse files, all files that are largely empty are stored in the normal fashion thus occupying disk space they don’t really need by filling empty blocks with scores of zeros. In JFS such blocks can be represented by brief metadata, but no actual space will be allocated to them.


Yet, no things in this life are totally “bombproof” and JFS is no exception: it also has its downside that needs to be considered.


To begin with, this file system doesn’t journal changes to user files, so a system crash or a hard reboot may result in the loss of your data. If you use a quality recovery tool, you are likely to bring your files back, though their original names will presumably fail to be restored.

Secondly, the version of JFS used in Linux is not so actively developed and maintained in comparison to more popular options like, for instance, ext or even XFS, and, therefore, there are much fewer people who can answer your questions or have the necessary expertise to help you if you happen to have any problems with this file system.


Furthermore, although JFS partitions can be dynamically resized, they do not support shrinking, so if you want to reduce the size of a partition, you will need to transfer all your data to another drive and then repartition.

In all, JFS boasts low resource usage and is actually a good choice for battery-powered devices like laptops or computers that are short of CPU. Moreover, it has good performance with both large and small files which is a rare quality, since, as a rule, file systems tend to shine in just one thing. However, at some point, the lack of support for this file system may become a problem.

Share This Story

Get our newsletter