Another possible cause: at the beginning of a "dsmc inc ..." job, the
TSM server sends the client lots of metadata, ie, a list of the files
it currently has.
The client then walks its local disk to see what's changed.
If the client has 10 million files, that metadata can be significant.

You can sort this out node-by-node using Servergraph, which reports a
data type called "overhead" (maybe [nodename_ovhd?), exactly what
you're talking about.
So you can see WHICH client is doing this the most.
Or you can dig it out yourself from the accounting log ... I forget
exactly how...


------
Mr. Lindsay Morris
Principal
www.tsmworks.com
919-403-8260
lindsay AT tsmworks DOT com




On Jun 11, 2009, at Jun 11, 3:30 PM, Shawn Drew wrote:

Wow, it's amazing how much data is caught up in retries.  On one of
our
larger instances, the amount transferred is 2.8TB but only 1.3TB was a
part of the storage pool backup!
Are retries the only explanation of this?


Regards,
Shawn
________________________________________________
Shawn Drew





Internet
rbs AT BU DOT EDU

Sent by: ADSM-L AT VM.MARIST DOT EDU
06/11/2009 02:33 PM
Please respond to
ADSM-L AT VM.MARIST DOT EDU


To
ADSM-L
cc

Subject
Re: [ADSM-L] Internal compression?






On Jun 11, 2009, at 2:14 PM, Shawn Drew wrote:

Is there any reason that STGPOOL backups and Migrations would only
process
about half the quantity of data that is reported to be backed up?

One commonly encountered reason is retries, evidenced in the full
client log.  (It's a product deficiency that the summary statistics
don't report the retries in any way, so you have to pore over the full
log.)

   Richard Sims



This message and any attachments (the "message") is intended solely
for
the addressees and is confidential. If you receive this message in
error,
please delete it and immediately notify the sender. Any use not in
accord
with its purpose, any dissemination or disclosure, either whole or
partial,
is prohibited except formal approval. The internet can not guarantee
the
integrity of this message. BNP PARIBAS (and its subsidiaries) shall
(will)
not therefore be liable for the message if modified. Please note
that certain
functions and services for BNP Paribas may be performed by BNP
Paribas RCC, Inc.