All filesystems necessarily write data in chunks. In the event of a power outage, system crash, or other problem, the disk may be left in an unstable condition as a result of a half-completed operation. The result can be lost data and disk errors down the line. In order to head off such problems, modern filesystems support a dirty bit. When Linux mounts a filesystem, it sets the dirty bit, and when it unmounts the filesystem, Linux clears the dirty bit. If Linux detects that the dirty bit is set when mounting a filesystem, the OS knows that the filesystem was not properly unmounted and may contain errors. Depending on /etc/fstab or mount command options, Linux may run fsck on the filesystem when its dirty bit is set. This program, described in more detail in the upcoming section, "Recovering from Filesystem Corruption," checks for disk errors and corrects them whenever possible.
Unfortunately, a complete disk check on a traditional filesystem such as ext2fs takes a long time, because the computer must scan all the major disk data structures. If an inconsistency is found, fsck must resolve it. The program can often do this on its own, but it sometimes requires help from a person, so you may have to answer bewildering questions about how to fix certain filesystem problems after a crash or other system failure. Even without answering such questions, disk checks of multigigabyte hard disks can take many minutes, or potentially even hours. This characteristic may be unacceptable on systems that should have minimal down time, such as many servers.
Over the past decade Journaling filesystems have received increasing attention as a partial solution to the disk check time problem. A journaling filesystem keeps an on-disk record of pending operations. When the OS writes data to the disk, it first records a journal entry describing the operation; then it performs the operation; and then it clears the journal. In the event of a power failure or crash, the journal contains a record of all the operations that might be pending. This information can greatly simplify the filesystem check operation; instead of checking the entire disk, the system can check just those areas noted in the journal as having pending operations. The result is that a journaling filesystem takes just a few seconds to mount after a system crash. Of course, some data might still be lost, but at least you won't wait many minutes or hours to discover this fact.
Linux supports four journaling filesystems:
Ext3fs This filesystem is basically just ext2fs with a journal added. As such, it's quite reliable, because of the well-tested nature of the underlying ext2fs. Ext3fs can also be read by an ext2fs driver; however, when it's mounted in this way, the journal will be ignored. Ext3fs also has another advantage: As described in the upcoming section, "Converting Ext2fs to Ext3fs," you can convert an existing ext2 filesystem into an ext3 filesystem without backing up, repartitioning, and restoring.
ReiserFS This filesystem was the first journaling filesystem added to the Linux kernel. As such, it's seen a lot of testing and is very reliable. It was designed from the ground up as a journaling filesystem for Linux, and it includes several unusual design features, such as the ability to pack small files into less disk space than is possible with many filesystems.
JFS IBM's JFS was developed in the mid-1990s for AIX, then it found its way to OS/2 and then to Linux. It's therefore well tested, although the Linux version hasn't seen much use compared to the non-Linux version or even ext3fs or ReiserFS on Linux.
XFS SGI's XFS dates from the mid-1990s on the IRIX platform, so the filesystem fundamentals are well tested. It's the most recent official addition to the Linux kernel, although it has been a fairly popular add-on for quite a while. XFS comes with more ancillary utilities than does any filesystem except ext2fs and ext3fs. It also comes with native support for some advanced features, such as ACLs (see the upcoming section, "Securing a Filesystem with ACLs"), that aren't as well supported on most other filesystems.
For the most part, I recommend using a journaling filesystem; the reduced startup time makes these filesystems beneficial after power outages or other problems. Some of these filesystems do have drawbacks, though. Most importantly, some programs rely upon filesystem quirks in order to work. For instance, as late as 2001, programs such as NFS servers and the Win4Lin emulator had problems with some of these journaling filesystems. These problems have been disappearing, though, and they're quite rare as of the 2.5.54 kernel. Nonetheless, you should thoroughly test all your programs (especially those that interact with disk files in low-level or other unusual ways) before switching to a journaling filesystem. The safest journaling filesystem from this perspective is likely to be ext3fs, because of its close relationship to ext2fs.
ReiserFS and JFS are also somewhat deficient in terms of support programs. For instance, neither includes a dump backup utility. XFS's dump (called xfsdump) is available from the XFS development site but isn't shipped with the xfsprogs 2.2.1 package, although some distributions ship it in a separate xfsdump package. The xfsdump and the ext2fs/ext3fsdump programs create incompatible archives, so you can't use these tools to back up one filesystem and restore it to another.
Was this article helpful?