[OpenAFS] OpenAFS future ramblings

[Neulinger, Nathan]

> > 3) Record locking, otherwise known as "block" or=20
> "byte-range" locking.
> > Some people are using Samba and can't switch just for this=20
> reason alone.
> > I've never heard many good things about NFS's implementation of it.
>=20
> 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=20
> nicer if you
> had transaction semantics that said
> "do {try lock" .. "do stuff" "on failure continue".. "} while=20
> (release lock =3D=3D retry);"
> but that would require changing unix semantics.  Ubik does=20
> work this way.
> Some hardware architectures also support machine instructions=20
> that manage
> spin locks similarly.

Actually, I've got a single-client-only implementation mostly planned
out, but not implemented. Basically, it boils down to one client
managing the byte range locks locally, but upgrading them to whole-file
locks on the server. This takes care of many of the concerns with byte
range locking which are single-client in nature, and still keeps it
compatible with all existing client and server implementations.

Without MAJOR changes to how the afs protocol works, there is no way to
have it work across multiple systems.

> > 4) A lightweight, easily portable client. I heard something=20
> about a kAFS
> > that someone was working on awhile back on this last, but=20
> google isn't
> > showing me much.  Anything going on for this?  I think the=20
> emphasis was to
> > throw away some of the little-used features in an attempt=20
> to get an AFS client
> > on every system out there without having to port the whole shebang.
>=20
> What features would you discard?  I think arla has the most=20
> interesting
> approach here: simple generic kernel interface, most of the complexity
> in userland.

Slow though... Actually, the afs client is very portable. kAFS is doing
the exact opposite - it's making a very NON-portable client.=20

OpenAFS is the ONLY file system that is available on almost ALL commonly
used platforms. No other file system comes anywhere even close.=20

> > 5) Client cache on Linux journaling filesystems.  I know=20
> it's the fault
> > of Linux that this isn't supported yet, but has anyone made=20
> the kernel
> > maintainers aware of the need for improvement here?
>=20
> 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?

The client cache works JUST FINE on journalling file systems. It is
solely reiserfs that it has a problem with because you cannot retrieve a
file from an inode number. Ext3 works just dandy for cache partitions.
In fact, on many of my machines (and after January 6th, all 140+ of
them), the cache partition is ext3, and everything else is reiserfs.
File server is running on reiserfs for it's vice partitions as well.

-- Nathan