Date: Tue, 22 Jan 2008 09:26:19 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: "Marc G. Fournier" <scrappy@hub.org> Cc: freebsd-afs@freebsd.org, jcw@highperformance.net Subject: Re: AFS in FreeBSD ... Message-ID: <20080122091915.Q58270@fledge.watson.org> In-Reply-To: <680043819D80C655D73D0DEB@ganymede.hub.org> References: <B0DF5151ECAB3953AB48EACA@ganymede.hub.org> <20080121103924.H73025@fledge.watson.org> <680043819D80C655D73D0DEB@ganymede.hub.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 21 Jan 2008, Marc G. Fournier wrote: >> I'm not sure there's a benefit to importing the OpenAFS server into the >> FreeBSD src tree, given that it's already well-maintained and fairly >> functional as a port. The main area of potential benefit is, in fact, the >> Arla client, which would then be able to track FreeBSD VFS changes, and >> offers a relatively static interface to the userland components that could >> continue to live in the port. >> >> After chatting with a few of the OpenAFS folks, the current concensus is >> that the OpenAFS client kernel parts are a lot more involved than the Arla >> ones, as much of the cache manager is implemented there, whereas with Arla >> it's just a user file system interface and so a lot less complex. > > Not arguing against it, but if OpenAFS puts the cache manager in the client, > and Arla doesn't have it ... what do we lose going with Arla vs OpenAFS? Sorry, maybe I was unclear -- the Arla model, similar to Coda, is that you have a small kernel module that is basically a user file system service, and a complex user process that manages shipping objects around the distributed file system, then exposes them using the kernel module. This user process is referred to irregularly as the "cache manager" because its job is really to do all this Coda/AFS stuff and then plop the results down on the disk cache and hand them off to the kernel module, which will make them look like a file system hung off /coda or /afs. I'm not really familiar with OpenAFS, but my second-hand understanding is that a lot more of that cache management logic goes in the kernel module and much less into a user daemon (if any). So it's not that OpenAFS puts it in the client, it's that it puts it in the kernel. Among other things, this means that the Arla/Coda kernel modules are relatively static over time, since they offer a fairly fixed interface to the user daemon where the real work happens, but the OpenAFS module changes a lot. >> So I think the short-term plan, if the Arla folks are willing and we can >> get a functional Arla module sync'd to 8-CURRENT, would be to get nnpfs >> into FreeBSD's src/sys. > > What about 6 and 7? Its going to be, what, a year+ before 8.0 is released > ... seems a long time to send people looking for this sort of thing over to > OpenSolaris or Linux :( Is this something we're going to either be able to > get into 6/7, or get a port for this to those versions? Things go into HEAD first, and 7-STABLE looks a lot like HEAD right now so if it's updated for HEAD it will basically be updated for 7-STABLE. The sooner we get it into HEAD, the sooner it can go into 7-STABLE, and the more easily. But the key concern here is trying to stop the perpetual falling behind that nnpfs suffers from due to the pace of FreeBSD VFS development. The theory is that if we get it into HEAD, perhaps it will stop falling behind because, rather than becoming a maze of ifdefs and requiring lots of hacking to update to a multiple-year-old release, it gets updated as part of the great VFS rush and requires only minor tweaking when someone notices that something has gone wrong. Robert N M Watson Computer Laboratory University of Cambridge
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080122091915.Q58270>