[OpenAFS] Roadmap for features

[Horst Birthelmer]

On Nov 8, 2004, at 2:50 PM, Mike Burns wrote:

> 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?

If Jeffrey says so ... :-)
We'll see.

>
> - 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?
>

I had it running for a rather short period of time on AIX and nobody 
complained but it was more of a nice backup access to the system than 
real use and therefor consider it "untested".

You can still run a userspace NFS-server on Linux (I did that one, 
too). It's a little bit slower but it works. If you use that as a main 
access to your system consider installing AFS clients.
I know, this is less difficult to say than to do.

> - UBIK best host algorithm rather than lowest IP#.
>

Who is best?? Who gets the veto??
Lowest IP is just one of many solutions, actually one that's already 
there.

> - File level ACLs.

We had this talk before. I don't know anything about any project 
regarding this topic.
We'll get a lot of trouble in OpenAFS with that but maybe it's a good 
topic for the Hackathon, too.

>
> - Volume names longer than 22/31 characters.
>

Is this a "must have" or just a "want to"... ???

> - 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.

In your tests, did you use the --fastrestart switch on configure??

>
> - 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?
>

That depends on what you want to backup and when. I think we don't have 
the resources to compete with TSM.
Do we actually want to??

You cannot do a filelevel incremental backup when your atomic units of 
the system are volumes unless you use AFS as a normal filesystem and 
backup it like any other filesystem by use of the client. Maybe 
somebody comes up with a clever idea on this one. You can backup your 
partition for example from the fileserver or something like that.

Horst