Date: Wed, 16 Jan 2008 16:47:14 -0500 (EST) From: Jeffrey Hutzelman <jhutz@cmu.edu> To: Robert Watson <rwatson@FreeBSD.org> Cc: rra@stanford.edu, port-freebsd@openafs.org, freebsd-fs@FreeBSD.org, matt@linuxbox.com, freebsd-afs@FreeBSD.org, "Jason C. Wells" <jcw@highperformance.net>, openafs-devel@openafs.org, freebsd-questions@FreeBSD.org Subject: Re: [OpenAFS-devel] Re: AFS ... or equivalent ... Message-ID: <Pine.LNX.4.33L.0801161639120.7669-100000@minbar.fac.cs.cmu.edu> In-Reply-To: <20080116203521.K15541@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 16 Jan 2008, Robert Watson wrote: > On Wed, 16 Jan 2008, Jeffrey Hutzelman 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. > > Right now we maintain a relatively stable VM/VFS KPI withing a major release > (i.e, FreeBSD 6.0 -> 6.1 -> 6.2 -> 6.3), but see fairly significant changes > between major releases (5.x -> 6.x -> 7.x, etc). I expect to see further > changes in VFS for 8.x (and some of the locking-related ones have already > started going in). Yup; that's a reasonable process. > The historic problem for Arla has been that instead of tracking these VFS > changes as they are made, they had to catch up every once in a while. Normally > that "every once in a while" has been at the point where a FreeBSD branch is > coming to the end of support rather than when it is new and shiny. Yes, that's a problem you're likely to run into unless you have a community of developers who are interested in keeping current versions working for their own use. For example, we tend to have relatively little trouble getting people to spend time making OpenAFS work on Linux or Solaris (sometimes we have trouble _getting_ it to work, but that's a different story). > In the case of > Arla, there's a quite logical path: if we import the nnpfs kernel module (but > not cache manager), then it will track FreeBSD development and almost > certainly work with little or no trouble on new major releases, as sweeps to > various KPIs will happen "for free". Yes. In fact, I think NetBSD has already done that. > So let's turn the question around: to get the OpenAFS client up and running on > FreeBSD, do you have any technical requirements not yet met by FreeBSD I don't think we know the answer to that... > , or is > it really about finding someone willing to spend some time doing the bulk of > the technical work and track bugs for a while? because this _is_ a significant part of the problem. So for starters, I think we're looking for someone who has some familiarity with OpenAFS and/or with FreeBSD's VFS layer, or thinks they can fake it, and who has cycles they're interested in spending on this. I'm sure such a person would be welcome on the openafs-devel list. -- Jeff
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.LNX.4.33L.0801161639120.7669-100000>