[OpenAFS-devel] Re: [OpenAFS] 2020 AFS Technologies Workshop Cancelled.. kafs update
Giovanni Bracco
giovanni.bracco@enea.it
Mon, 6 Apr 2020 10:17:45 +0200
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.bracco@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
>
--
Giovanni Bracco
phone +39 351 8804788
E-mail giovanni.bracco@enea.it
WWW http://www.afs.enea.it/bracco