Why is JFS so obscure?

Question

When I first got into using Slackware years ago I quickly learned to love JFS over ext3 or reiserfs given that it was reliable and if there was an unclean shutdown, its disk checking was very very quick. It's only been recently that I've found out that JFS is obscure to the point of being almost completely unmaintained by anyone.

I had no idea I was in such a minority. Why is it that this happened? Is it that filesystem technology has since advanced to the point that JFS now lacks any comparative advantages? Is it that ext3 was more interoperable with other operating systems? Was a particular other filesystem blessed by a particular vendor or the kernel developers?

Not so much a technical question as a historical one.

Answer 1

The first thing you have to get out of the way is the comparison to ext[234]. Replacing any of them is going to be like replacing NTFS in Windows. Possible, sure, but it will require a decision from the top to switch.

I know you're asking about keeping existing alternatives, not removal of other alternatives, but that privileged competition is sucking up most of the oxygen in the room. Until you get rid of the competition, marginal alternatives are going to have an exceptionally hard time getting any attention.

Since ext[234] aren't going away, JFS and its ilk are at a serious disadvantage from the start.

(This phenomenon is called the Tyranny of the Default.)

The second thing is that both JFS and XFS were contributed to Linux at about the same time, and they pretty much solve the same problems. Kernel geeks can argue about fine points between the two, but the fact is that those who have run into one of ext[234]'s limitations had two roughly equivalent solutions in XFS and JFS.

So why did XFS win? I'm not sure, but here are some observations:

• Red Hat and SuSE endorsed it.

  RHEL 7 uses XFS as its default filesystem, and it was an install-time option in RHEL 6. After RHEL 6 came out, Red Hat backported official XFS support to RHEL 5. XFS was available for RHEL 5 before that through the semi-official EPEL channel.

  SuSE included XFS as an install-time option much earlier than Red Hat did, going back to SLES 8, released in 2002. It is not the current default, but it has been officially supported that whole time.

  There are many other Linux distros, and RHEL and SuSE are not the most popular distros across the entire Linux space, but they are the big iron distros of choice. They're playing where the advantages of JFS and XFS matter most. These companies can't always wag the dog, but in questions involving big iron, they sometimes can.

• XFS is from SGI, a company that is essentially gone now. Before they died, they formally gave over any rights they had in XFS so the Linux folk felt comfortable including it in the kernel.

  IBM has also given over enough rights to JFS to make the Linux kernel maintainers comfortable, but we can't forget that they're an active, multibillion dollar company with thousands of patents. If IBM ever decided that their support of Linux no longer aligned with its interests, well, it could get ugly.

  Sure, someone probably owns SGI's IP rights now and could make a fuss, but it probably wouldn't turn out any worse than the SCO debacle. IBM might even weigh in and help squash such a troll, since their interests do currently include supporting Linux.

  The point being, XFS just feels more "free" to a lot of folk. It's less likely to pose some future IP problem. One of the problems with our current IP system is that copyright is tied to company lifetime, and companies don't usually die. Well, SGI did. That makes people feel better about treating SGI's contribution of XFS like that of any individual's contribution.

• In any system involving network effects where you have two roughly equivalent alternatives — JFS and XFS in this case — you almost never get a 50/50 market share split.

  Here, the network effects are training, compatibility, feature availability... These effects push the balance further and further toward the option that gained that early victory. Witness Windows vs. OS X, Linux vs. all-other-*ix, Ethernet vs. Token Ring...

Answer 2

As someone who has worked extensively with JFS on Linux and have delved into the source code to fix issues I can assume several reasons:

1. JFS is a port of a filesystem created for AIX, then ported to OS/2, and then open sourced. It has none of the developers of the AIX working on it since there's a risk of code contamination, and OS/2 was not developed for quite some time.
2. From my code reading and following the development of JFS I saw plenty of issues in the code (one of them was failure of resizing the FS on big-endian machines, i.e. the ones made by IBM) that were fixed by the project and were not merged into the mainline kernel even months after the fix, probably because that the IBM developers were not officially the maintainers of that part of the tree.
3. The code has many readability issues, that probably contributed to the lack of official support by distributions, since code that is hard to read is hard to debug.
4. I assume one of the main uses in the beginning of JFS for Linux was to migrate information and share information with AIX systems, but in AIX5L there was no (supported) option to use the filesystem on a simple disk without with the proprietary LVM used by AIX, which was not available for Linux, and JFS was extended without these extensions being ported to Linux (see number 1).

Clarification: Despite working in IBM in the past, I was never a member of the IBM AIX development team or the JFS development team and these assumed reasons are based on my logic deduction and familiarity with the history of the filesystem and Linux.