Thank you for the news!
I have tried for the first time the kafs client on a Fedora 31 and it
worked really nicely, I am very impressed by how it is simple to have it
working. Of course I have no be able to make a massive test yet, but it
look really interesting
My feeling is that to put it really in production the main missing
points are:
1) pam module
2) user commands, essentially "fs" first of all and also "pts"
3) inotify
The bos, vos and backup command can be run on server nodes, which can be
standard OpenAFS systems, am I right?
Giovanni
On 02/04/20 19:06, David Howells wrote:
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-i...@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
--
Giovanni Bracco
phone +39 351 8804788
E-mail giovanni.bra...@enea.it
WWW http://www.afs.enea.it/bracco
_______________________________________________
OpenAFS-devel mailing list
OpenAFS-devel@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-devel
