Giovanni Bracco <giovanni.bra...@enea.it> wrote:
> In the present complicate situation, it would be nice to have some news about
> the latest development both of OpenAFS and kafs
The status of kafs can be found at:
https://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 fileserver
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 fscache:
- Moving culling into the kernel
- Better indexing support
- Disconnected operation support
For kafs-utils (which provides the command suite), I've started rewriting that
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
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
