From owner-freebsd-afs@FreeBSD.ORG Tue Jan 22 09:26:26 2008 Return-Path: Delivered-To: freebsd-afs@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 731CC16A41B for ; Tue, 22 Jan 2008 09:26:26 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 2DF9213C447 for ; Tue, 22 Jan 2008 09:26:26 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id ACF8D46DF5; Tue, 22 Jan 2008 04:26:19 -0500 (EST) Date: Tue, 22 Jan 2008 09:26:19 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: "Marc G. Fournier" In-Reply-To: <680043819D80C655D73D0DEB@ganymede.hub.org> Message-ID: <20080122091915.Q58270@fledge.watson.org> References: <20080121103924.H73025@fledge.watson.org> <680043819D80C655D73D0DEB@ganymede.hub.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: freebsd-afs@freebsd.org, jcw@highperformance.net Subject: Re: AFS in FreeBSD ... X-BeenThere: freebsd-afs@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: The Andrew File System and FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jan 2008 09:26:26 -0000 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