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 <lind...@tsmworks.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 > lind...@tsmworks.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 >> r...@bu.edu >> >> Sent by: ADSM-L@VM.MARIST.EDU >> 06/11/2009 02:33 PM >> Please respond to >> ADSM-L@VM.MARIST.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. >> >
