[OpenAFS-devel] A few questions about the current Linux implementation of the AFS client
Derrick J Brashear
shadow@dementia.org
Fri, 18 Jan 2002 15:44:57 -0500 (EST)
On 18 Jan 2002, Derek Atkins wrote:
> > 3 - The AFS Client implementation on Linux is poorly designed and very
> > unstable to the point that reboots become common place.
>
> I'm not sure what you mean by "poorly designed". The client on Linux
> is pretty much the exact same code as the client on every other
> platform. The only difference are the specific hooks into the Linux
> kernel (vs. Solaris, Irix, Tru64, AIX, BSD, etc). OpenAFS works on
> all the platforms with a common source tree. This is considered a
> feature.
It's poorly integrated with Linux; We've been making changes in that
direction. Obviously if there's going to be a serious effort to rewrite
the client, that's a strategic decision which should be considered as it
will presumably divert the scarse development resources to something other
than the code we have now, unless you know where we can find more
developers. It's not necessarily a bad idea on that basis, it's just
something to consider.
> Third, the majority of the code still needs to be portable to other
> OSes. There are only so many linux-specific "hacks" that I believe
> will be allowed into the mainline sources. However, don't quote me,
> I'm not a gatekeeper.
A Linux-only client means double the resources necessary to maintain (that
plus the "other" client). If those resources are forthcoming, great!
> I think there is definite forward progress on OpenAFS development.
> Some of the problems you've pointed out are "known" problems, but
> nobody has had the time or initiative to work on them. However I
> would argue that changing how afs/afsd works for Linux is not a good
> use of your time. Changing the Linux-specific interfaces to better
> hook into the Linux kernel would DEFINITELY be a good use (e.g. use
> the kernel inode table instead of creating matching inodes in AFS).
> Just my humble opinion, mind you.
Unless you have resources to devote to this, and to maintenance after, I
agree with Derek.
-D