[OpenAFS] TSM client for OpenAFS

[Harald Barth]

> we are currently deploying OpenAFS here at the university and also are stuck with TSM
> for backups.

There could be worse things. PDC uses TSM and we use homwgrown logic
to do full and incremental dumps. These then are piped into a program
that uses the API. The only problem is that we do not have a tool for
the users to request restores. But this has not been a too pressing
burden yet.

> Currently there doesn't seems to exist any good AFS backup client for TSM,

The company with the dinasaur? name (teradactyl.com) makes one, but
last when I applied their pricing to my department size it was not so
attractive any more. I addition we need TSM anyway and for TiBS I
would have needed a seperate infrastructure in front of the tape
library.

> and just storing volume dumps is not too appealing, both due to backup storage space and
> simpleness in restoring single files.

Why is the space bigger? Don't you do incremental dumps?

> So I have written a client that uses the TSM API for backup.  

I suspected some ongoing work for AFS backups (considering your
earlier questions).

> It reads the data directly out
> of a volume and store all files in TSM as objects, while preserving ACLs, mountpoints etc.
> Doing it this way will let AFS backups use the policies for objects, and also restores can
> be performed via dsmc if necessary.

Nice.

> There are a few nits, though, that I haven't found a good way to handle.  Any suggestions
> are welcome :-)
> 
> First is the storage of AFS data inside of TSM.  TSM has three identifiers for an object:
> - filespace (typically mount point)
> - High-level name (path inside mount point)
> - Low-level name (filename)
> Ideally the filespace should be the volume name, but TSM gets _really_ slow if there are
> too many (a few hundred) filespaces.  Currently I just give it the cellname, and stores
> the volume name in the HL name (like /volume/path-in-volume).  Other ideas?

Good that you have tested the filespace == volume thing. But the
question "what happens when you have some hundred filespaces" could be
a relevant one to the TSM 6 devel team. (TSM 6 is a major redesign I
was told).

Another numbers question: We have currently at least 98434720 files in
our cell. I don't know how TSM would react with that in one filespace
either.

> Second is the storage of attributes and ACLs.  There is a 255-byte space available for
> storing object attributes connected to each object.  This is not enough to store the ACLs
> as clear-text, so I have to do pts lookups to translate them to their internal numbers
> and store as such in the attribute block.  Any better ideas of how to do this?

Another question is when to backup the contents of a directory and
what to store along with the directory and what along with the file.
Plan for future file ACLs?

Harald.