[OpenAFS] TSM client for OpenAFS

[Anders Magnusson]

Mattias Amnefelt wrote:
>>
>>> 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).
>>
>>   
> I've been thinking about how to do this myself. My latest idea was to
> modify the arla client and have it write data to TSM using the API. It
> hasn't progressed much further than an initial idea though.
I looked at arla-cli but it was the cache manager involved in it, and I
just wanted to stream data.
I used the raw calls following the examples in the (quite outdated :-)
AFS FS programming
manual.

>>> 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?
>>>     
>> There are a few nits, though, that I haven't found a good way to
>> handle. Any suggestions
>
> My idea was to use the single filespace and have
> HL=/volume/path-in-volume too. I'm almost certain administrators who
> do QUERY FILESPACE don't want several 100k filespaces listed.
:-) Yes, it looked "funny" :-)

>>> 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?
>>>     
>>
>>   
> The volume dumps which we store contain ACLs in their binary formats
> and also requires pts to be useful, so you wouldn't be much worse of
> than we are :)
The RXAFS_FetchACL() call returns them as a text string, so I must add
pts talk code
to do the translation.  I had hoped to avoid that :-)

> Note however, that an AFS acl can be as large as 1024 bytes so you
> cannot be certain to store it in a 255 bytes space.
>
> The idea I had was to store one file in the root of the volume for the
> volume metadata and one per directory for the file metadata. I'm not
> sure whether to use a binary format or a text format (XML?) though.
>
I thought about something similar; to have an internal-only file with
the necessary things. Haven't
decided yet, but it is a reasonable way of doing it.  Maybe in next
version :-)

-- Ragge