ADSM. Mailing List dec 2000 :AW: Slow restore for large NT client > What I think is happening is this: > Due to the incremental forever backup method the files are becoming > fragmented on the tapes. A file changes so a new version is > written to the > tape. The oldest version is then deleted leaving a gap on > the tape. The > problem with fragmented tapes is that the seek speed of the > tape drives is > very slow. This is also my opinion and you should have a look at the managementclasses: If you have 3 additional versions of a file and all of the data fits onto a single tape you have only 25% (1+3/100) information on that tape - means only 25% throughput... With Regards Stefan Holzwarth > -----Ursprüngliche Nachricht----- > Von: Geirr Halvorsen [mailto:[EMAIL PROTECTED]] > Gesendet am: Montag, 29. Januar 2001 14:31 > An: [EMAIL PROTECTED] > Betreff: Incredibly slow restore > > Hello people, > one of my customers is running into the following problem; > With TSM server 3.7 on NT 4 sp6a, and TSM client 3.7 on NT4 > sp6a, restore > is really slow. Checking all normal parameters in both server > and client > .opt files does not seem to help. My suspiscion is then > turned to network > issues, but according to the customer, they do not have any network > problems. > > When I restore using the client GUI, and watch the status > indicator, when a > file reaches 100%, it waits for a long time (bigger file - > longer time) > before it continues with the next, I have also watched > performance/utililzation of CPU, memory and network traffic, > on both client > and server while doing this, and none of these indicates that > something is > unusual. Both CPU and mem is low, network is maxed, but drops > when a file > is done. The result is a throughput somewhere around 950MB > per hour. Not > very impressing. > > Is this likely to be a TSM problem, or in other words - where > should I go > from here? > > Any suggestions will be helpful! > > > Geirr Halvorsen > Tech, Consultant > FourLeaf Technologies > Denmark. >
