On Mar 13, 2006, at 12:24 PM, Remco Post wrote:

Well, actually, I can inmagine the TSM server allocating the
destenation
resource on a per file basis even for B/A client backups. This I
get, not from
any redbook, but both the quickfacts and 'help def stg'. Or is
there a verb in
the tsm protocol that says someting like: 'hey server! here's a
bunch of
files, the grand total is x bytes, make sure you're ready to store
it', where
bunch is defined by tnxgroupmax and movebatchsize?

You can refer to the description of transaction processing in the
Admin Guide manual, and the original description of Small File
Aggregation in the ADSMv3 Technical Guide, to appreciate the
mechanism and its controls. The combination of TXNGroupmax and
TXNBytelimit govern the transaction and Aggregate size. In modern TSM
servers, TXNGroupmax may be defined individually for each node.

The reason I'm asking:

I've done a query on the contents table that tells me:

1- the number of files in an aggregate
2- the size of the aggregate

This is about as much info as the server has during reclamation/
migration etc.
I'm trying to determine how large a maxsize setting would give me
how many %
of the total number of files and how many % of the total number of
bytes
stored. (so for eg. maxsize of 10MB I have 73% of the total number
of files
and they take up about 10% of the total data-volume). I then could
determine
the size of a 'FILE' pool to keep all 'small' files on-line for my
environment
at this point in time.

Now if the maxsize is _always_ the size of the aggregate, this is a
correct
figure (in my environment), but if in one case this is the size of an
individual file (B/A client) to be aggregated, and in another it is
the size
of the aggregate... I'm uhhh, trouble because I'll need a larger
file pool for
that setting (or I'll end up migrating files to tape that I don't
want to
store on tape).

Aggregation distances logical file size from the MAXSize value: you
have coarse, rather than fine control. You could conceptually reduce
your client TXNBytelimit, but that then applies to all transmissions,
and could impair performance. (Note the huge jump in the default
TXNBytelimit value in TSM 5.3, for performance.) MAXSize is thus a
reasonableness value for storage pool apportionment rather than a way
of having only files in a certain size range stored in a given
storage pool.

In considering all this, appreciate that TSM is an Enterprise
product, intended to deal with large volumes of data, en masse. Its
controls are by classes of data rather than by specific object
attributes, such as size. The objective is overall throughput speed,
to keep today's high volume of data moving. Keeping small files
separate from large files is not a product objective, where relative
age is a more common differentiator for restorals, and thus migration.

   Richard Sims