[OpenAFS-devel] Re: AFS ... or equivalent ...
kyle at moffetthome.net
Mon Feb 4 06:24:25 UTC 2008
On Jan 16, 2008 1:48 PM, Jeffrey Hutzelman <jhutz at cmu.edu> wrote:
> The "let's just slurp everything into the main distribution so we don't
> have to worry about stable interfaces" approach is really poor. It
> encourages bad engineering practice among people maintaining the main
> distribution, discourages innovation and extension by others, and generally
> doesn't scale. It's far better to either attempt to maintain stable
> external interfaces to the VFS and VM subsystems, or else admit that you
> don't have the resources to do so given the relatively small number of
> external users, in which case you almost certainly also don't have the
> resources to keep on top of updates to something like OpenAFS.
The Linux Kernel presents a very strong counter-argument-by-example.
The amount of patches merged per released version has been linearly
increasing over the last several years; the 2.6.23 => 2.6.24 patch was
49MB uncompressed, with a 5.7MB changelog. Of that, a significant
portion were VFS changes which touched most filesystems. The various
filesystem-related changes alone between 2.6.23 and 2.6.24 were
2.9MB. For reference, the *entire* OpenAFS diff between 2.4.6 and
2.5.30 is all of 8.2MB. The Linux Kernel changes include partial
support for having per-process views of a single filesystem
(Specifically /proc, so /proc/net can have differing contents between
network namespaces). Other features which Linux supports that
virtually no other OS does is multiple filesystem namespaces, where
the mount-tree is selectively independent or shared between
I realize that some people are probably already aware of most of that,
but I thought it should be mentioned that "slurp everything into the
main distribution" actually scales very well with respect to the Linux
kernel. It means that the people who are making changes (to the VFS,
for example) have to go around and fix *all* the filesystems, and in
addition when a bug gets fixed in one filesystem then most of the
others get checked for that same bug.
OpenAFS also does not benchmark very well under Linux against most of
the other networked filesystems (even ones using encryption), as it
does not support the fine-grained locking that Linux does.
Unfortunately it isn't practical for Linux to reuse existing OpenAFS
code as the licenses are partially incompatible.
> In the long run, I'm guessing that the OpenAFS cache manager evolves more
> quickly than FreeBSD's VFS interface, which makes pulling the CM into the
> kernel tree a losing battle. If you disagree, by all means fork that part
> of AFS (or get someone else to do so) and see what happens (AFS's
> user/kernel and RPC interfaces are both fairly stable, so forking just the
> kernel parts should be mostly feasible).
As it so happens this is exactly what is happening right now in the
Linux Kernel. David Howells (original author of the Linux "keyring"
subsystem) has been writing a generic userspace+kernelspace FS-Cache
system which can use either a block device or a mounted filesystem as
storage. It presently supports NFS and the minimal in-kernel AFS
client and is planned to be mostly merged into 2.6.25. The benefits
of being able to share innovations in caching between AFS, NFS, and
other networked filesystems is quite significant.
My apologies for anything in this email that may be construed as
offensive; the intent is as an honest technical discussion of
development methods and practices.
More information about the freebsd-questions