Nick Petreley wrote last year that Linux needed three items to become more fault-tolerant, and thus better able to compete on high-end boxes in the enterprise. Those three things were a journaling filesystem, fault tolerance, and data clusters. Someone must have been listening; Linux now has four, count 'em, four journaling filesystems in the cooker. Those filesystems, and the pending 2.4 kernel's vastly improved scalability, won't give Nick everything he asked for, but will surely make Linux more attractive to users of high-end systems.

One company that listened to Nick must have been IBM, which, believe it or not, has become a major player in Linux and open source. IBM's initial Apache flirtation has blossomed into a virtual organization called the Linux Technology Center (LTC).

Under the LTC umbrella, IBM has become involved in many diverse projects, supported by teams positioned around the world. IBM is working on the logical volume manager (LVM), kernel performance and scalability, the OMNI project for open source print drivers, the IA-64 port, the PowerPC port, the S/390 port, the Linux Standard Base, and a journaling filesystem called JFS. You can learn more about each of those projects at the LTC page. This column deals with the port of JFS from AIX to Linux.

I know, the ReiserFS is much further along, and will almost certainly be the first journaling filesystem included in the 2.4 kernel. ext3 is coming along too, as is SGI's entry in the race, XFS. But JFS has an advantage: the hometown edge. LTC's JFS team is located right here in Austin, Texas. Steve Best, who leads the small team working on JFS, gave the Austin LUG an informal presentation on the port's status just a few weeks ago. I was there; Best said that the project, working on open source code and with the open source community, was the best job he had ever had.

Journaling filesystems defined

For those who aren't familiar with the ins and outs of journaling filesystems, here is the lowdown. The filesystem writes a journal that keeps track of where data has been written or removed. For example, as you receive a file you are FTPing, the file consumes more disk space as extents grow or new ones are added. An extent, by the way, is a group of contiguous blocks of data.

The journal keeps track of where the filesystem puts each extent. Then, if your system crashes, you can be back up and operational much more quickly with a journaling filesystem. Instead of having to remap the filesystem from scratch by relinking the data, a journaling filesystem can use the journal entries to do the job. For a busy e-commerce site, for example, there is a critical difference between an outage of less than a minute and an outage of an hour.

However, a journaling filesystem like JFS -- which does not journal data, only the metadata that allows it to quickly puzzle out what data belongs with what file -- can still lose data in the event of a crash. Fast recovery is more important than a guarantee that there will be no data lost. It can take hours, even days, for a large, busy site with a nonjournaling filesystem to restore service. With JFS, it only takes seconds or minutes.

There is a performance penalty involved in using a journaling filesystem, since the system writes more data when it keeps a diary. But a small penalty is definitely worthwhile the first time your system crashes and fsck runs. JFS has reduced that penalty by switching from synchronous logging to asynchronous. With synchronous logging, journaling occurs in direct proportion with any qualifying filesystem action. Using asynchronous logging, journaling happens less and can take place when it won't interfere with other filesystem operations, thus reducing the journaling overhead.

IBM's JFS

At the LUG meeting, Best explained that JFS journals in the classic database-transaction model. For those of you who don't have a database or fault-tolerant background, and who are interested in exploring the subject, I recommend an article by Juan I. Santos Florido in Linux Gazette.

Best also listed some items still being developed for JFS: support for character devices in the JFS fsck utility, case-sensitive filename support, Endian support for non-Intel platforms, and completion of the logging capabilities.

Best is tight-lipped about when IBM may complete the Linux port, but he did say that the company is "working with the community and the distributors to potentially have JFS included in the [2.4] kernel." When I asked him how the port will compare with JFS on AIX, he replied, "The JFS team's goal is to have a competitive high performance enterprise filesystem on Linux."

You can download and use JFS today, but it is not yet complete and should probably be used only for evaluation. Still, that's good progress for a project announced earlier this year. The latest drop (12) came out on Sept. 15. The JFS patch and tar files support three levels of the kernel: 2.2.14, 2.2.16, and 2.4.0-test7. Actually, a patch for a later test version of 2.4 may be ready by the time this column appears. Check the JFS page to be sure.