Linux: Protect data with journaling filesystems
One of the first choices a new Linux user will be faced with during installation is which filesystem to use for Linux partitions. At the moment, there are no less than 5 native Linux filesystems to choose from, some or all of which are supported by various distributions, and all of which bring different attributes to the table. This tutorial is not intended to be an overly technical discussion of B-tree structures and inodes, but rather a simple overview to give the new Linux user a starting point in choosing the right filesystem for the job.
First, a little discussion of journaling vs. non-journaling filesystems.
When Linux boots up and mounts filesystems, fsck (the Linux equivalent of scandisk) is called to examine each filesystem and be sure it is in a useable state before it is mounted. If the system was halted uncleanly due to a power failure or system crash, fsck will detect that the filesystem was not cleanly unmounted and run an exhaustive check to correct any errors it finds. On extremely large filesystems, this check may take up to an hour. The problem is obvious: You may not be able to afford that much downtime while the system boots. At best, long fsck times are annoying. At worst, they can cost you a lot of money on critical systems.
Enter journaling. Filesystems use an internal structure called metadata to keep track of where data is actually stored, sort of like an index of the filesystem. When data is written to the filesystem, an entry is made in the metadata indicating its location. During fsck checks, the metadata is compared to the actual data to be sure everything is intact and uncorrupted. Journaling filesystems add a second structure called a journal, and each change in the metadata is logged before the change is written. After an unclean shutdown, the system can compare the journal to the metadata without having to examine the entire filesystem. Startups go from several minutes to a couple of seconds in most cases.
This distinction in filesystems also exists in the Windows world: NTFS is a journaling filesystem, while FAT32 is not. That's why Windows 9x will always run scandisk after a system crach, whereas Windows 2000 or XP running on NTFS will not.
Only a year ago, one of the major criticisms of Linux in the enterprise was the lack of a journaling filesystem. Today, Linux has 5 native filesystems, 4 of which are journaling. BTW, filesystem fragmentation is not an issue with Linux filesystems (at least not like it is with NTFS and FAt32), so there is no need to defragment any of these filesystems.
Ext2
This is the tried and true Linux filesystem that's been around for simply ages, and until very recently was the default filesystem for all Linux distributions. Ext2 is a non-journaling filesystem and is currently in the process of being phased out. With journaling filesystems having reached maturity, there isn't much reason to use ext2 these days unless you're one of those ultra-conservative Debian types who won't use anything unless it's been out for at least 2 years. :)
ReiserFS
ReiserFS was the first journaling filesystem for Linux, making its initial appearance as patches for the 2.2 kernel series and finally being included in the official kernel as of 2.4.1. Mandrake and SuSE were among the first Linux distributions to support ReiserFS, while some, such as Red Hat, still do not. ReiserFS has been plagued with problems, both political and technical, since its introduction. ReiserFS uses a radical new high-performance filesystem structure, and its performance is simply amazing, especially with lots of small files. However, although ReiserFS has performed well for the vast majority of users, there have been sporadic reports of data corruption and data loss with ReiserFS under certain conditions. Depending on who you believe, these problems are the result either of problems in the structure of the filesystem or of changes in other parts of the kernel that didn't play nicely with ReiserFS.
The good news is that ReiserFS seems to have finally stabilized and these problems have largely gone away. Despite its checkered past, ReiserFS is now a solid choice for most systems. Interestingly, ReiserFS seems to hold the most promise for the future because it supports filesystem plug-ins, an as-yet unrealized potential its developers seem intent on exploring in the future.
XFS
XFS is a journaling filesystem developed in the early '90s by Silicon Graphics for use in its high-end IRIX workstations. XFS is an ultra-high performance 64-bit filesystem, and it is extremely scalable, supporting files up to a theoretical limit of 8,388,608 terabytes. Is that big enough for you? :D In 1998, SGI decided that the inherent limitations of ext2 were a roadblock to its long-term Linux strategy, so SGI made the decision to release the source code to XFS to the Linux community under the GPL.
Although XFS is currently at the 1.1 release and is deployed in a number of critical production environments, it is not yet included in the official Linux kernel because it introduces major kernel changes. It is currently only available as a kernel patch, but it should be included in the upcoming 2.6 kernel series. XFS handles extremely large files very well, and uses a unique method of delayed allocation to reduce fragmentation and increase performance. XFS performance is generally close to that of ReiserFS, although it is very slow at performing file deletes, an issue which is currently being addressed in development.
JFS
JFS is, like XFS, a scalable and robust 64-bit journaling filesystem donated to the Linux community by IBM from its AIX operating system. However, I'm not going to spend much time on JFS except to say that its feature set is comparable to XFS but otherwise unremarkable. However, despite a gold release, JFS has not found a large audience because it was late to reach maturity and failed to offer compelling features not found in the other journaled filesystems. Basically, IBM was a day late and a dollar short with JFS. Additionally, JFS is still considered somewhat experimental and has not yet been merged into the official kernel release, although I understand it has finally made an appearance in 2.4.20-pre4. JFS is not officially supported in most Linux distributions. (Mandrake is the only one I know of that supports it.)
Ext3
Now we come to my personal favorite, ext3. As the name implies, ext3 is the successor to the venerable but tired ext2, and in fact is the *same* as ext2 with the exception of the extra journaling structure. Ext3 is attractive to upgraders because existing ext2 filesystems can be converted to ext3 nondestructively and back again with the "tune2fs -j" command (provided you have kernel support for ext3), so there's no need to reformat with the new filesystem. Just issue a few keystrokes and you're ready to go. If you're upgrading a legacy system and don't want to reinstall, ext3 is the only way to go.
Ext3 also includes one feature that none of the others do: it supports journaling of not only metadata, but also the physical data of the filesystem, providing an extra layer of security for your data. Metadata-only journaling, while reducing boot times by eliminating fsck checks, does little to protect the integrity of actual data. Data that may not have been flushed from the cache to disk before a crash, for example, may become corrupted or lost. This extra logging may be activated in ext3 by adding the data=journal option to the filesystem in /etc/fstab and by passing the rootflags=data=journal option to your bootloader (either lilo or grub). For very critical systems where data integrity is paramount, ext3 becomes a very attractive option indeed. Ext3 has been included in the official kernel since 2.4.15.
Summary
Most users should probably choose ext3 in the absence of a good reason to use one of the others. Ext3 is built on the venerable ext2 structure, provides extra journaling to protect data, and can be converted back and forth from ext2 easily. Performance is not as quite as high as XFS and ReiserFS, but it is a mature and stable filesystem for everyday use. If you use applications that access lots of small files on a regular basis (like a squid proxy) or if you simply value performance above all else, ReiserFS makes a good choice because of its exceptional small file performance. Conversely, if you handle lots of large files regularly (like during audio or video editing), XFS handles those files very well due to its unique method of delayed allocation, although performance suffers badly on file deletes. JFS is still somewhat experimental and its use should probably be limited to testing, if your distribution even supports it at all.
Additional resources:
Ext3 Filesystem Usage
IBM's JFS for Linux Homepage
SGI's XFS for Linux Homepage
The ReiserFS Homepage
