[OpenAFS] 2020 AFS Technologies Workshop Cancelled.. some update anyway?
David Howells
dhowells@redhat.com
Thu, 02 Apr 2020 18:06:35 +0100
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