On 8/28/2017 3:55 AM, Harald Barth wrote: > >> a half-measure probably isn't worth the effort > > If you care about a more flexible license, for the client, it might be > worth reviving Arla. The concept with a small kernel module and a > userland daemon is different from OpenAFS as well. Another idea would > be to port the relevant parts to the FUSE interface instead (both Arla > and OpenAFS are older than FUSE). > > Harald.
Hi Harald, The Arla architecture is similar to the OpenAFS Windows Redirector architecture. The kernel module implements all of the required VFS functionality and a userland process is responsible for implementing all of the cache management, the Rx network stack, the RXAFSCB service, and all of the VL and RXAFS RPCs. This approach reduces complexity by removing the Rx networking and cache management file operations from the kernel. I'm not sure the reduced complexity saves all that much considering that the OpenAFS Rx stack was implemented in kernel for prior versions of OpenBSD. There is also a performance cost since upcalls from the kernel module to the userland process must be performed to satisfy the requests delivered through the VFS. As for FUSE, the OpenAFS cache manager has been implemented as a FUSE module. Unfortunately, there remains a significant unresolved design question: "How to implement path ioctls for FUSE?" Without pioctls the OpenAFS command line tools can not be used for token management or otherwise manage the cache manager. Therefore, the existing FUSE implementation only supports anonymous operations. Jeffrey Altman
<<attachment: jaltman.vcf>>
smime.p7s
Description: S/MIME Cryptographic Signature
