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
