Re: Reiser4 Inclusion

[Erik Mouw <erik@harddisk-recovery.com>]

On Mon, Jul 17, 2006 at 08:13:04AM -0700, Jeff Anderson-Lee wrote:
> In the past I've wondered why so many experimental FS projects die this
> death of obscurity in that they only work under FreeBSD or some ancient
> version of Linux.? I'm beginning to see why that is so:? the Linux core
> simply changes too fast for it to be a decent FS R&D environment!

That hasn't been a problem for OCFS2 and FUSE (recently merged), and
also doesn't seem to be a problem for GFS.

> I have been looking at implementing a COW archival file system for Linux on
> and off for some time now.? While I had hoped to develop these new FS ideas
> under Linux, so that they could have a longer life-time and wider exposure,
> that seems to be a pipe dream with the current situation.? The file system,
> VFS, and mm code has been changing so much lately it would be like trying to
> build on quicksand.? The LKML has such a high volume that I cannot afford
> the time to follow it 100%, but issues that would affect FS development are
> often raised there, instead of in linux-fsdevel.? linux-mm often contains
> issues that would affect linux-fsdevel without cross posting.? The overhead
> of following all of these lists is a huge burden of time that subtracts for
> the time available for development (and the rest of my job).

A good MUA is very important to follow high volume lists (I use Mutt
and Sylpheed, anything that supports threading should do): skim the
subjects, delete any thread you're not interested in. The result is
quite a small amount of useful posts. If you still think linux-kernel
is too much, linux-fsdevel should do. In my experience the important
changes go there first (or are CC'ed from linux-kernel).

> I saw a log-structured file system being developed as a Google summer
> project recently.? It's likely doomed to obscurity by the fs-related
> code-churning in the Linux kernel.? Since it is "experimental" it won't be
> included in the kernel distribution and hence won't get the benefit of
> kernel developers making sweeping changes that touch all the file system
> dependent code.? You practically need it to be your full-time job in order
> to do any research or development work under Linux with this kind of
> environment.

FYI the amount of vfs changes is quite small. Use git to figure out:

  git-log v2.6.12..v2.6.17 | git-shortlog | grep -i vfs | grep -vi devfs | wc -l
  57
  git-log v2.6.17..v2.6.18-rc2 | git-shortlog | grep -i vfs | grep -vi devfs | wc -l
  15

There's some clutter in those numbers, so the real amount is even
smaller. Your claim about a high amount of changes in the vfs code
doesn't seem to be backed by evidence from the kernel changelog.

> The frequent chant of LKML is "don't write a new f/s, make changes to an
> existing FS".?? While there is much merit to this approach it limits the
> ideas that can be tried to small incremental changes.? Also, since every
> existing f/s is essentially considered as "production", each change must be
> vetted by the LKML -- not ideal for "experimentation".
> 
> Things that could make Linux a better environment for FS development might
> include:
> 
> 1) Create a F/S "sandbox" where experimental FS can be added that will be
> benefit from sweeping changes that affect f/s specific code, or

You can use FUSE for that: your fs lives in userspace where you can
experiment at will. FUSE will take care of the kernel specific things.
 
> 2) A lessening (moratorium?) on sweeping changes for a while, so that FS
> developers would have a chance to try new ideas without being flooded with
> changes needed just to keep up with the latest kernel, or

See Documentation/stable_api_nonsense.txt.

> 3) Better isolation of the FS dependent and FS independent code, so that
> fewer sweeping changes are needed.
> 
> Of these: (1) is likely impractical, as it imposes an additional burden on
> kernel developers to support obscure or experimental f/s.? (2) is only a
> stop-gap, as at some point sweeping changes might again be made that would
> out-date most experimental f/s.? (3) seems the most logical course: work
> towards a better interface between the FS dependent and independent layers
> (e.g. VFS, mm) that does a better job of isolating the layers from each
> other.

I opt for option (4): accept that the number of changes are low enough
to follow for any filesystem.

> Without that, *BSD (and now possibly OpenSolaris) will be preferred over
> Linux for FS research, which typically means that few if any people benefit
> from the results: a loss for both Linux and the community at large.

IMHO that's just FUD. High rates of change haven't obstructed Linux in
any way to get a larger installed base than Solaris and *BSD.


Erik

-- 
+-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 --
| Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/