[OpenAFS] Roadmap for features

Mike Burns burns@psu.edu
Mon, 8 Nov 2004 08:50:05 -0500 (EST)


Greetings,

At Penn State we eventually (next 18 months or so) need to migrate away
from DCE/DFS and to something else.  OpenAFS is one of the choices we're
considering for replacing DCE/DFS.  We used AFS before we moved to DCE/DFS
and have been testing OpenAFS a little since last fall.  There are some
features that we're used to having in DCE/DFS that work differently or are
currently missing from OpenAFS.  I'm hoping to receive some comments on
the status of these features - development is in progress, not in
progress, not likely, easy to implement, difficult, whatever.  Some of
these already appear in the Project List on openafs.org but it appears to
be a little out of date and I'd like to hear the current status.

- Native Kerberos 5 and support for multiple strong (better than single
DES) encryption types.  I've used the migration toolkit patch to get K5
support, but would rather not have to do that each time we upgrade to a
new version of OpenAFS.

  Jeffrey Altman already informed me that this will be worked on at the
  AFS Hackathon next month and make it into OpenAFS 2.0, but that it
  would not be stable enough for the 1.4 release.  There may not be
  anything more to add to this..  Is there a projected timeframe for
  the release of 1.4 and 2.0?

- A secure RPC / packet privacy.  This should be solved by above, right?
We'd like to enforce packet privacy for secure file service on the file
server side like in DCE/DFS and not rely on the client admin to remember
to enable it.

- AFS/NFS translator for any one of Solaris, AIX or Linux.  I tried it on
Solaris 9 and encountered knfs issues as per bugid 1480.  Does it work
well on any of these three platforms now?

- UBIK best host algorithm rather than lowest IP#.

- File level ACLs.

- Volume names longer than 22/31 characters.

- Faster fileserver process start up and stop times.  This has improved
greatly from when we used to use AFS, but can still be slow for large
number of volumes on a server.  At some point after 10K-40K volumes are on
a (Solaris 9) server start/stop times can jump from less than 30 seconds
to a handful of minutes and even 10-20 minutes.  We'll have a minimum of
160K volumes.  We probably have enough file servers now to stay around
10K volumes per server, but if we decide to use .backup volumes that
number will double and we may hit the performance inflection point.

- Incremental file level backups.  I haven't looked into this with
OpenAFS.  We've always used IBM's TSM which supported backing up/restoring
ACLs for files and directories with DFS and AFS.  Do any backup products
support this for OpenAFS or would we have to back up an entire volume at a
time?

Thanks for any information you can provide on these items.

- Mike

--------------------------------------------------------------------------
Mike Burns                                     Emerging Technologies Group
burns@psu.edu                  Academic Services and Emerging Technologies
+1 814 863 5606                          The Pennsylvania State University