[OpenAFS] OpenAFS future ramblings

[Ryan Underwood]

hi,

Well, it seems that OpenAFS is maturing quite well.  Kudos to all the people
who have spent long hours hammering it into shape.

I just wanted to rattle off a list of things that I hear people complaining
about AFS, and wondering if they are solved problems, can be solved within
the framework of AFS, or cannot be solved at all.  I don't even know if these
are really problems, it's just that everytime I suggest AFS to somebody as
a solution, they've already got some gripe about it for some reason. ;)

1) Special files, such as Unix named pipes, device nodes, etc.  I can't mknod
a file on AFS, nor can I mkfifo.  I'm sure this is obvious to those more
"in the know" on AFS, but is this fundamentally impossible?  It would be
fairly cool, for instance, if a program on one machine were able to write
to a fifo on AFS, and a program on another machine can read that data from
the fifo.  Perhaps if we can't use "standard" Unix fifos or pipes, we could
create an AFS construct specifically for that purpose that would be usable
in the same fashion as a Unix pipe.   Again, I'm rambling here, and I freely
admit to not knowing enough about the protocol to know whether this is
totally stupid.

2) Hard links.  I don't know why people want or need them.  But, is it
impossible?

3) Record locking, otherwise known as "block" or "byte-range" locking.
Some people are using Samba and can't switch just for this reason alone.
I've never heard many good things about NFS's implementation of it.

4) A lightweight, easily portable client. I heard something about a kAFS
that someone was working on awhile back on this last, but google isn't
showing me much.  Anything going on for this?  I think the emphasis was to
throw away some of the little-used features in an attempt to get an AFS client
on every system out there without having to port the whole shebang.

5) Client cache on Linux journaling filesystems.  I know it's the fault
of Linux that this isn't supported yet, but has anyone made the kernel
maintainers aware of the need for improvement here?

6) Better SMP scalability.  I have no basis for comparison, but people tell
me that the process management mechanism AFS uses does no good for
multi-processor performance. (locking increases so much as you add CPUs that
the performance gain is vaporized, or something to that effect)

So, if anyone wants to add anything to the list or shoot down any of these
so-called concerns, feel free to.

-- 
Ryan Underwood, <nemesis at icequake.net>, icq=10317253