On Jan 16, 2008 1:48 PM, Jeffrey Hutzelman <[EMAIL PROTECTED]> 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 namespaces. 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. Cheers, Kyle Moffett _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
