[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AFS in FreeBSD ...
- To: "Marc G. Fournier" <scrappy_(_at_)_hub_(_dot_)_org>
- Subject: Re: AFS in FreeBSD ...
- From: Robert Watson <rwatson_(_at_)_FreeBSD_(_dot_)_org>
- Date: Tue, 22 Jan 2008 09:26:19 +0000 (GMT)
- Cc: freebsd-afs_(_at_)_freebsd_(_dot_)_org, jcw_(_at_)_highperformance_(_dot_)_net
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
Robert N M Watson
University of Cambridge
freebsd-afs_(_at_)_freebsd_(_dot_)_org mailing list
To unsubscribe, send any mail to "freebsd-afs-unsubscribe_(_at_)_freebsd_(_dot_)_org"