OMFS and the value of obscure filesystems

Your editor has never dabbled in filesystems development. He has a suspicion, however, that there is a tense moment in every new filesystem developer's life: when Christoph Hellwig's review shows up in the mailbox. Christoph's reviews, while not always being pleasant reading, tend to be right on the money with regard to problems in filesystem implementations - and problems in new filesystems are common. Christoph's stamp of approval is almost required for the merging of a filesystem, so, when the initial posting of a filesystem is greeted with reviews that read, nearly in their entirety, "looks good," one would assume that the path into the mainline would be straightforward.

The story of OMFS, though, shows that this assumption does not always hold. Reviewers have only been able to find the smallest of details to fix, but there is opposition to its merging, especially from Andrew Morton. The objection is that this filesystem - found on devices like the Rio Karma music player and ReplayTV boxes - has a very small user base. OMFS developer Bob Copeland, in his initial posting, suggested that fewer than twenty people might be using it at this time. New devices with this filesystem are no longer being made, so the chances of the user base growing significantly are small.

Andrew's objection is that the addition of any new code creates a new maintenance burden for kernel developers. Whenever a VFS interface is changed, all filesystems must be fixed to work with the new API. So the addition of a filesystem imposes costs which, he says, should be outweighed by the benefits that new filesystem brings. In the case of an obscure filesystem with a small and (presumably) decreasing user base, says Andrew, it is not clear that the benefits are sufficient. He asks:

Andrew would rather see OMFS turned into a user-space filesystem using FUSE. Chris Mason is also concerned:

OMFS supporters note that the code is written well and can serve as an example for other filesystem authors. They also note that code with small user bases is often merged - that, in fact, in some areas, developers have said they want all code, regardless of how few people are using it. Running OMFS through FUSE, they say, would be harder for users to set up and less efficient in operation. Says Christoph:

In this case, it looks like Andrew will back down on this one and let the next version of the OMFS patches into -mm. From there, if all goes well, it could make the jump into the mainline, possibly as early as 2.6.27. But Andrew is clearly unhappy about that outcome, and may well raise the question again in the future: is "well written" really sufficient to justify merging new filesystems into the kernel?

---

(Log in to post comments)

I went looking to see if there were any redeeming merits to this filesystem that might justify
using it other than for interoperability with existing hardware that uses it.  It doesn't
sound like it's all that charming of a filesystem.

Ah well.

You should definitely try out OMFS then, along with libkarma.
http://linux-karma.sourceforge.net/Karma-HOWTO.html is a good place to start.  The banshee
plugin has bit-rotted a tad, but everything else should be more or less current.

There is a lot of code which is rarely used in the kernel. Around 2.6.8-2.6.9 I needed a
driver (ArcNet) which clearly hadn't been used since some time in 2.5. But I fixed the bug,
submitted a patch and later on at least one other person have fixed a bug in the driver, and I
see a few janitory changes around.

Clearly not many people are using this driver. But because it was still in the mainline kernel
it was keeped up-to-date wrt. interface changes and compile-tested. It was untested and
contained a bug, which was fairly simple to fix. If the driver wasn't in the mainline, I am
pretty sure I would never had got around to get ArcNet to work in Linux at all, since it was
only a "private" experiment at my former job. 

I can't see why a file system should be different.

The only other way to make sure Linux supports a lot of old stuff, is to make a stable API and
be backward compatible. But how easy would it be to make it possible to (compile and) load a
2.4 driver into a 2.6 kernel with no modifications?
I am not even sure a "micro kernel" (like using fuse) approach would help much. The interfaces
might be much more stable, but over a long period they will be changed. But will they get
compiled checked as they are in Linux now?

Backward compatibility in fuse is guaranteed on multiple levels:

 - the raw kernel interface 
 - the library ABI
 - the library API

While new major versions of the library might come out in the future, the old versions will
still be usable.  Just like gtk-1.2 libraries are still around in distributions, many years
after gtk-2.0 has been released.

I agree though, that in case of drivers where a userspace soultion is not available, keeping
support for old hardware in the kernel is a good thing.

I agree with Andrew. Something new with such few users should be in user space.

How do you ensure you have no bugs in your code? Have no code! Of course we need code for
useful things. But OMFS sounds like it does not meet the useful criterion. In the spirit of
code-minimization, adding code of such limited utility to the maintained code base sounds
silly to me.

It's hard to justify not bringing in OMFS when I know for a fact that there's  code for
prototype hardware boards *that never saw production* in the mainline.  Code for which there
were under 6 boards made. ever. Suddenly 20 guys using OMFS sounds like quite the crowd!

I don't see the difference between a file system driver for obscure hardware and a chip driver
for obscure hardware.   They've been hyping how easy it is to get a well-enough-written chip
driver into the kernel.  Resistance here appears to sully that message.  

That said, there seems to be a lot of effort to divert USB hardware drivers to user-space
libraries, which is probably all to the good. I suppose the difference is that FUSE is not the
standard installation that USB libraries and the generic drivers they depend upon are.  Fixing
that is a job for the distributions.

That move does exist, but only for devices with no concurrent uses and no established kernel
interface -- scanners, for example.

It's not limited to USB either; the Firewire DV driver was likewise deprecated.

I seem to remember a presentation from a leading kernel hacker that urged hardware vendors to
merge their drivers to the mainline even if it has only one user. I can't find that
presentation right now, but did something changed since then?

There's a fundamental difference between "the first user" and "the last user."