[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [OpenAFS-devel] Re: AFS ... or equivalent ...
- To: Jeffrey Hutzelman <jhutz_(_at_)_cmu_(_dot_)_edu>
- Subject: Re: [OpenAFS-devel] Re: AFS ... or equivalent ...
- From: "Rick C. Petty" <rick-freebsd_(_at_)_kiwi-computer_(_dot_)_com>
- Date: Wed, 16 Jan 2008 18:09:42 -0600
- Cc: rra_(_at_)_stanford_(_dot_)_edu, port-freebsd_(_at_)_openafs_(_dot_)_org, freebsd-fs_(_at_)_FreeBSD_(_dot_)_org, Robert Watson <rwatson_(_at_)_FreeBSD_(_dot_)_org>, matt_(_at_)_linuxbox_(_dot_)_com, freebsd-afs_(_at_)_FreeBSD_(_dot_)_org, "Jason C. Wells" <jcw_(_at_)_highperformance_(_dot_)_net>, openafs-devel_(_at_)_openafs_(_dot_)_org
- Reply-to: rick-freebsd_(_at_)_kiwi-computer_(_dot_)_com
On Wed, Jan 16, 2008 at 01:48:52PM -0500, Jeffrey Hutzelman wrote:
> --On Monday, January 14, 2008 02:23:47 PM +0000 Robert Watson
> <rwatson_(_at_)_FreeBSD_(_dot_)_org> wrote:
> >I'd like very much to get at least the kernel parts of an AFS client into
> >the base system.
> That may well be realistic for arla, though I believe there was a period
> for a while where the kernel/arlad interface was evolving to support
> features like chunking. I pay only superficial attention to arla-drinkers,
> so I don't know what the status of any of that is; for that, you'd have to
> ask someone who is actively involved in arla development (I believe there
> are some such people on this list).
> It is unlikely ever to happen for OpenAFS, in which virtually all of the
> cache manager code is in-kernel and most of it is cross-platform. Trying
> to pull the OpenAFS cache manager into the FreeBSD kernel would be
> equivalent to forking OpenAFS; what you'd get would work and would keep up
> with FreeBSD, but it would be unlikely to keep up with OpenAFS.
> 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.
> 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).
> -- Jeff
> freebsd-fs_(_at_)_freebsd_(_dot_)_org mailing list
> To unsubscribe, send any mail to "freebsd-fs-unsubscribe_(_at_)_freebsd_(_dot_)_org"
-- Rick C. Petty
freebsd-afs_(_at_)_freebsd_(_dot_)_org mailing list
To unsubscribe, send any mail to "freebsd-afs-unsubscribe_(_at_)_freebsd_(_dot_)_org"