[OpenAFS-devel] Re: [OpenAFS] 2020 AFS Technologies Workshop Cancelled.. some update anyway?

[David Howells]

Giovanni Bracco <giovanni.bracco@enea.it> wrote:

> In the present complicate situation, it would be nice to have some news a=
bout
> the latest development both of OpenAFS and kafs

The status of kafs can be found at:

=09https://www.infradead.org/~dhowells/kafs/todo.html

There is now a filesystem-afs subpackage that provides the /afs mountpoint =
as
part of the filesystem package in Fedora and others.  I'm trying to get it
into the LSB also.

There is now a kafs-client package in Fedora and others that provides
configuration, systemd services and DNS upcall handling plus an aklog.

I'm currently rewriting the operation handling in kafs to improve fileserve=
r
failover and rotation and so that I can support asynchronous I/O.

I'm also rewriting local filesystem caching in Linux (fscache) to:

  - Use async direct I/O to the backing filesystem (which is a lot faster)
  - Not use bmap to track contents (which isn't guaranteed with extents)
  - Be lazy about metadata writeback (reducing metadata ops)
  - Provide better handling of versioned files (eg. directories)
  - Use of larger I/O granules on the network (256K rather than PAGE_SIZE)
  - Code simplification (3-4000 LoC removed)

All in all, it's looking a *lot* faster.  I also have on my radar for fscac=
he:

  - Moving culling into the kernel
  - Better indexing support
  - Disconnected operation support

For kafs-utils (which provides the command suite), I've started rewriting t=
hat
in C because the Python language subtleties keep changing and breaking it.
Also I've been asked for a C/C++ version so that Python libraries are not
required.  The plan now is to put a swig interface on top of it.

David