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:
Just as a thought exercise: should we merge a small and well-written
driver which has zero users?
Andrew would rather see OMFS turned into a user-space filesystem using
FUSE. Chris Mason is also concerned:
Even though OMFS seems to be using the generic interfaces well,
there is still a testing burden for every change. Someone needs to
try it, report any problems and get them fixed. Since none of the
people making the changes is likely to have an OMFS test bed, all
of that burden will fall on Bob, his users, and anyone who tries to
compile the module (Andrew).
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
Moving a simple block based filesystem means it's more complicated,
less efficient because of the additional context switches and
harder to use because you need additional userspace packages and
need to setup fuse.
We made writing block based filesystems trivial in the kernel to
grow more support for filesystems like this one.
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?
to post comments)