[OpenAFS] Roadmap for features

[Horst Birthelmer]

On Nov 8, 2004, at 4:47 PM, Mike Burns wrote:
>
>>> - 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??
>>
>
> No I did not.  I think that when reading the description of what the 
> fast
> restart option did, it implied I would have to pay more attention to
> restarts and manually running the salvager when it was needed rather 
> than
> having it run automatically.
>

You're right about that. There is no free lunch ...

>>>
>>> - 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.
>>
>
> I found a couple of references since sending this email.  A product 
> called
> TiBS and someone who had written a taracl program that saves the ACLs.
>

I have no idea why someone wants to do a tar of acls and restore them 
later or worse somewhere else. That's behavior you won't get with a 
'native' filesystem either ...
but there are a lot of possibilities out there :-)

Horst