[LSF/MM ATTEND] Jeffrey Eric Altman and Marc Dionne

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux