Dear program committee, I am the founder and CTO of AuriStor, Inc., the developer of AuriStorFS, https://www.auristor.com/filesystem/, a 21st century follow-up to AFS. Although I have never directly contributed to the Linux kernel I believe I can make a meaningful contribution at the LSF/MM face-to-face. At AuriStor, we believe that the /afs file namespace continues to have a crucial role to play in distributed systems. Especially workflows involving federated authentication and data access across internal, dmz and cloud infrastructures. IBM AFS 3.6 which became OpenAFS 1.x is fundamentally unchanged since 1989. All of the capabilities and limitations that existed then do so today. Still, the core concepts are more relevant today than ever: * data location independence permits data replication and migration without outages from the perspective of applications * the security framework protects against MITM attacks and provides negotiable authentication mechanisms as well as hash and encryption algorithm agility * one standard global namespace permits all devices connected to the internet to access any data provided that appropriate rights have been granted * federated authentication and a platform independent access control model permits authorization to be granted to external users. * as a true distributed file system and not a copy & sync file sharing service, the /afs file namespace can be used for real-time collaboration and synchronization. AuriStorFS preserves the /afs file namespace and the Rx RPC protocol. AuriStorFS serves the namespace to AFS3 and AuriStorFS clients with a new implementation that removes many functional, throughput, scale and security limitations. I believe that the AuriStorFS implementation of the /afs file namespace and its combined identity authentication and multi-factor authorization model are an excellent solution to problems surrounding * Linux container migration * Linux container network identity assertion * Linux container persistent storage However, for /afs to be that solution there must exist a production quality in-tree filesystem client. Since long before I joined the leadership of OpenAFS in 2005 there has been significant friction between GPL_ONLY licensed kernel interfaces and the OpenAFS filesystem kernel module which is licensed under the IBM Public License 1.0. The OpenAFS developer community which has been resource starved since the inception of OpenAFS in 2000 never had the resources to write a new Linux file system kernel module from scratch and maintain the existing cross-platform Unix kernel module. David Howells has been working on the in-tree kAFS and the AF_RXRPC socket interface for more than a decade as a hobby project. Many core technologies in the Linux kernel including keyrings and FS-Cache were developed in order to support kAFS. As OpenAFS Gatekeeper I consistently redirected resources to assist David as best I could. Now that AuriStorFS is shipping commercially I have committed to not only assist David in completing kAFS for the AFS3 protocol but to extend it to support all of the AuriStorFS protocol and security enhancements. David maintains a status page for AF_RXRPC and kAFS: https://www.infradead.org/~dhowells/kafs/ There are still many open architectural questions that we need a consensus answer to: https://www.infradead.org/~dhowells/kafs/user_interface.html Most importantly, IBM AFS/OpenAFS implements a path-based ioctl kernel interface. Linus and other members of the Linux community have strong objections to adding pioctls to the Linux kernel. I am hoping that hallway conversations at LFS/MM can help refine a proposal and gain necessary support for adoption. AF_RXRPC is essentially completed. The AFS cache manager functionality works. The Python administrator tools are well on their way. Linux is the preferred server platform for AuriStorFS database and file services. AuriStor, Inc. has extensive experience optimizing our userland implementation of the Rx protocol for the Linux networking stack on both IPv4 and IPv6. AuriStor Rx pushes IPv6 in ways that few other applications have in the past. We also are a consumer of Linux filesystems as the backing store for the AuriStorFS file servers. AuriStor has already implemented new optimizations to take advantage of xfs reflinks support. We would be eager to share our implementation experience with the developers if they are present. I hope that you will see fit to invite myself and the lead Linux kernel developer at AuriStor, Inc., Marc Dionne <marc@xxxxxxxxxxxx>, to this year's LSF/MM. Thank you. Jeffrey Altman Founder and CTO AuriStor, Inc.
begin:vcard fn:Jeffrey Altman n:Altman;Jeffrey org:AuriStor, Inc. adr:Suite 6B;;255 West 94Th Street;New York;New York;10025-6985;United States email;internet:jaltman@xxxxxxxxxxxx title:Founder and CEO tel;work:+1-212-769-9018 note;quoted-printable:LinkedIn: https://www.linkedin.com/in/jeffreyaltman=0D=0A= Skype: jeffrey.e.altman=0D=0A= url:https://www.auristor.com/ version:2.1 end:vcard
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
