Putting my TSM knowledge together with my knowledge of how databases
work, I come up with the following understanding:
Each version of each file has an entry in the database. That entry
stores all the info about the file (size, mtime, any CRC values, etc., a
unique identifier used in other parts of the database).
Each version of each file is stored in one or more aggregates. Each
aggregate also has a record in the database that contains info about
that aggregate, which would include the size of the aggregate, where it
is stored, and what files are stored in that aggregate.
This is analogous to a Unix filesystem in that a file does not know what
directory it's in. The directory knows which files are in it. The file
knows its permissions, size, and access times, and the directory knows
its permissions and access times -- and what files are in that
directory. (A lot of people don't realize that in Unix, a directory is
just a different type of file that stores the names of other files.)
How'd I do?
BTW, is there a TSM internals redbook that I could read? Most of what I
find is administration stuff that doesn't really address this kind of
detail.
---
W. Curtis Preston
Backup Blog @ www.backupcentral.com
VP Data Protection, GlassHouse Technologies
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Paul Zarnowski
Sent: Monday, January 28, 2008 11:01 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] DISASTER: How to do a LOT of restores?
Curtis, I didn't read this whole thread, but I don't think this is quite
true. I believe that all files in an aggregate relate to a single
common
database entry which indicates where the aggregate is stored (which tape
or
disk volume, and location on that volume). When files in an aggregate
are
moved (i.e., migrated from disk to tape), then the one aggregate record
is
updated in the database to reflect that the aggregate was moved, but all
of
the individual file entries (that make up the aggregate) do not need to
be
updated.
So yes, each file it's own database entry, but that database entry
doesn't
necessarily indicate *where* the file is stored. That information is
kept
in an aggregate record.
It should still be true that if an aggregate transmission is
interrupted,
the entire transaction is rolled back.
The above is my understanding, but I do not know it as fact.
..Paul
At 03:54 PM 1/28/2008, Curtis Preston wrote:
>So I'm back to my original understanding then, that all files are
>tracked individually in TSM. It's just that TSM doesn't do a commit
>until an aggregate has completed. This explains why the entire
>aggregate must be redone if it fails halfway through due to a
>busy/locked file. If it fails, the entire transaction is rolled back,
>so there is no record of any of the previous files in the aggregate.
Am
>I still on the right page?
--
Paul Zarnowski Ph: 607-255-4757
Manager, Storage Services Fx: 607-255-8521
719 Rhodes Hall, Ithaca, NY 14853-3801 Em: psz1 AT cornell DOT edu
|
