The accounting log has multiple fields for the session:

backup transactions
backup KB
total transmitted

On a backup, you'll find the total transmitted is significantly higher than
the total backed up.
That's the difference in the metadata.

Now what I can't remember, is whether the backup KB includes the retries or
not....  Richard?

W

On Thu, Jun 11, 2009 at 3:43 PM, lindsay morris <lindsay AT tsmworks DOT 
com>wrote:

> 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.
>>
>