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