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
_______________________________________________ OpenAFS-info mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-info
