[OpenAFS] OpenAFS future ramblings

[Derrick J Brashear]

On Wed, 11 Dec 2002, Ryan Underwood wrote:

> 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

they wouldn't be portable if you could.

> "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

you want a producer/consumer construct? it would be doable "easily" if you
didn't care about more than one consumer, i think. once you have more than
one consumer it gets ugly.

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

cross-volume hard links won't work for the same reason cross-filesystem
hard links won't. you could do something ugly involving a fid from another
volume, but it would still be fundamentally a symlink

> 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.

if you want it on the host you're on, ok. if you want it across all hosts,
it's messy. something which appears as an advisory whole-file lock to
other clients *might* be doable without a lot of mess

> 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.

arla? i don't know what you mean, exactly.

> 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?

ext3 works fine, just like it did the last 50 times people asked. 

> 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)

server? client? everywhere?