[OpenAFS] OpenAFS future ramblings

[Marcus Watts]

"Ryan Underwood" <nemesis-lists@icequake.net> writes:
> 
> 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.

Usually people mention this in conjunction with chroot or machine
backups.

For "chroot" - the big problem is you are now representing machine
resources in shared space.  What does it mean to access a tape drive
that's in your network filesystem?  Does it go to your local tape
drive, or some tape drive across campus?  How do you map devices that
don't exist on some hardware, or features that don't map well, such as
block vs. character disk devices on a linux machine?  In unix, "mknod"
takes major/minor number; how do you store these numbers in a machine
independent fashion?
	[ What would probably be most handy here is
	if you had some sort of ability, on a per-machine basis, to mount
	local machine file space under AFS.  By making this part of the cache
	manager, and not part of AFS, I think that elimates most of the problems.
	Whether it's still worth it is another question. ]

For machine backups, I think the proper answer is to use dump or tar or
whatever, and store the flat file representation that results in AFS.

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

No, just difficult.  You'd have to change how files are stored in AFS,
you'd have to change the salvager (and you now have a more difficult problem
to solve because files could be anywhere in your volume not just confined
to one directory)), and you might have to change the "vos dump" format some.
You probably don't want to link files across volumes - so you won't gain
all that much.  Per-file acls would (IMHO) be more valuable.

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

Record locking is hard to solve on a network-wide basis.  Unix "lockf"
semantics aren't a good match for the problem.  It would be nicer if you
had transaction semantics that said
"do {try lock" .. "do stuff" "on failure continue".. "} while (release lock == retry);"
but that would require changing unix semantics.  Ubik does work this way.
Some hardware architectures also support machine instructions that manage
spin locks similarly.

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

What features would you discard?  I think arla has the most interesting
approach here: simple generic kernel interface, most of the complexity
in userland.

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

This is a per-system particular.  There is an interesting meta-problem
here however: how do you define portable interfaces for code that runs
in kernel land?  How much stuff do you want inside the kernel anyways?
For instance: does it make sense to talk about tcp connections managed
entirely inside the kernel?  DNS?  Kerberos?

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

The AFS cache manager probably still has "one big lock".  Doing fine grained
locking with lots of different data structures that interact with each
other is hard to do right.  It's even harder if the code and data
structures weren't designed to do this from the start.

					-Marcus Watts
					UM ITCS Umich Systems Group