Richard Sims wrote:
> On Mar 13, 2006, at 12:24 PM, Remco Post wrote:
>
> 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.
>
thanks, will look into that, again. I wasn't really impressed by the
clarity of the chapters when I read them, just yesterday ;-)
> 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.
>
ok, let's make this clear beyond any doubt:
I don't care either way, I like aggregates and I do appriciate their
benefits, but I do want to know every detail about how aggregation and
the maxsize parameter interact.
I don't want to reduce tnxbytelimit or tnxgroupmax, large transactions
are a must to keep performance up.
> 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.
>
:-)
Do realize that diskpool's currently will not be able to handle the
database backups of over 64GB, since the single object doesn't fit in a
diskpool volume (due to restrictions on the size of diskpool volumes).
I would of course love to have my active files (save for the huge ones)
on-line and inactive versions off-line. Unfortunately, that is in the
future.
Overall throughput is nice, but being able te restore small files in
seconds rather than minutes is a big seller. Having over 70% of all
single file resotres, inrespective of file-age, not put any load on
tape-drives could greatly increase customer satisfaction as well as
reduce the load on my tape-drives. I currently have only 8 9940B drives
and 4 9840C drives for TSM and investing 20-40 k$ in disk rather than in
tape could be justified. I do need correct info on these details to be
able to both justify the investment and predict it's impact. (and market
it to my customers and convince my boss).
With these file-sizes, for files larger than the maxsize I'm currently
thinking of the tape mount-dismount times are still substantial compared
to the data transfer time. But not having a tape-drive busy for 2-3
minutes for a single 1k (or even 10M) restore, which do happen a lot
more often than the 90Gig restores, would be worth cosiddering, if only
I could all the correct details about TSM's workings ;-)
About TSM being enterprise: tell that to those who don't store
140000000+ files or 80TB (time 2 for the copy stgpool) in a single TSM
server ;-) I do appriciate TSM, we do have a p630 move over 2TB per 12
hours without any problems. We're just looking for ways of increasing
customer experience without any disproportionate investment and thus
impact on the cost of backups.
> Richard Sims
So now for the question at hand, how do aggregation and the maxsize
parameter interact? Both during B/A and migration/reclamation?
(yes I didn't notice a direct answer to my question in your posting ;-))
--
Met vriendelijke groeten,
Remco Post
SARA - Reken- en Netwerkdiensten http://www.sara.nl
High Performance Computing Tel. +31 20 592 3000 Fax. +31 20 668 3167
PGP Key fingerprint = 6367 DFE9 5CBC 0737 7D16 B3F6 048A 02BF DC93 94EC
"I really didn't foresee the Internet. But then, neither did the
computer industry. Not that that tells us very much of course - the
computer industry didn't even foresee that the century was going to
end." -- Douglas Adams
|
