Directories are on a dirmc diskpool. Actually I only restored few directories, and the files were all in the last sub-directory.
On this particular server that is big the data isn't collocated. We collocated by group and this server isn't in any group. There were only 3 tapes involved, and although they are big, it should not take several hours just to find and restore 114 files. We're one of the last remaining users of TSM on z/OS, but that shouldn't be an issue or should it??? I got "Waiting for files" right away when I started the restore Regards Niklas -----Ursprungligt meddelande----- Från: ADSM: Dist Stor Manager [mailto:[email protected]] För Daniel Sparrman Skickat: den 7 september 2010 09:40 Till: [email protected] Ämne: [ADSM-L] Ang: 50Mb restored in 4.18h.... Hi there To begin with, TSM as a product has no issues with fast restores. If the data isnt placed correctly, restores might slow up though. - Did you restore files or files and directories? - Are you storing directories on tape or in a dedicated diskpool using DIRMC? - Considering it was only 117 files, the average sice was 427KB. Are you using collocated tape pools, or is there a chance the files was spread across the tape? When a restore takes this amount of time for just a small amount of size/files, it usually points towards files / directories being spread across the tape. Usually when doing restores of large fileservers (which I asume this is) sorting out what needs to be restored on the TSM server-side is what takes time, but since you got to "Waiting for files" pretty fast, I'd say you have files/directories spread widely across the tape. Best Regards Daniel Sparrman -----"ADSM: Dist Stor Manager" <[email protected]> skrev: ----- Till: [email protected] Från: Niklas Lundström <[email protected]> Sänt av: "ADSM: Dist Stor Manager" <[email protected]> Datum: 09/07/2010 07:02 Ärende: 50Mb restored in 4.18h.... Hello I just did a restore of 50Mb and it took 4h 18min If it had been 50Gb I wouldn't complain Total number of objects restored: 114 Total number of objects failed: 0 Total number of bytes transferred: 50.99 MB Data transfer time: 9,426.15 sec Network data transfer rate: 5.53 KB/sec Aggregate data transfer rate: 3.36 KB/sec Elapsed processing time: 04:18:55 The server has a lot of files, almost 7 million including the copypool. The TSM DB is really big, 180Gb and 94% full. TSM Server 5.5.4. Does anyone have a clue of why the restore took so long? It found what volumes to mount fast, but then the client was "Waiting for files from the server....." People here are complaining about TSM and that the restores takes long time and it's hard to defend it when the restore takes so long... Med vänlig hälsning Niklas Lundström Niklas Lundström Storage Administrator Swedbank AB (publ) 105 34 Stockholm Telefon: +46 (0)8 5859 5164 Mobil: +46 (0)70 24 76 345 Vi ber dig lägga märke till att detta e-postmeddelande kan innehålla konfidentiell information. Om du felaktigt blivit mottagare av detta meddelande ber vi dig informera avsändaren om felet genom att använda svara-funktionen. Vi ber dig också att radera e-postmeddelandet utan att skicka det vidare eller kopiera det. Trots att vi intygar att e-postmeddelandet och eventuella bilagor inte innehåller virus och andra fel som kan påverka datorn eller IT-systemet där det mottages och läses, öppnas det på mottagarens eget ansvar. Vi tar inte på oss något ansvar för förlust eller skada, som har uppstått i samband med att e-postmeddelandet mottagits och använts. _________________________________________________________________________________ Please note that this message may contain confidential information. If you have received this message by mistake, please inform the sender of the mistake by sending a reply, then delete the message from your system without making, distributing or retaining any copies of it. Although we believe that the message and any attachment are free from viruses and other errors that might affect the computer or IT system where it is received and read, the recipient opens the message at his or her own risk. We assume no responsibility for any loss or damage arising from the receipt or use of this message.
