Folks:
  TSM Server 7.1.7.200 running on Linux x86_64 (Red Hat 6.8)
  TSM client 7.1.6.0 running on what appears to be Red Hat 5.7 (kernel 
2.6.18-300.el5)

  Local system admin is performing a BMR on a system that has been backing for 
years to the same TSM node.  So there are a lot of old files being pulled down.

  What is puzzling me is that the session associated with the restore just 
mounted a volume from our copy storage pool:

tsm: ADSM7>select * from sessions where session_id=179758

       SESSION_ID: 179758
       START_TIME: 2017-11-16 11:00:50.000000
       COMMMETHOD: Tcp/Ip
            STATE: MediaW
     WAIT_SECONDS: 2933
       BYTES_SENT: 10329945
   BYTES_RECEIVED: 883
     SESSION_TYPE: Node
  CLIENT_PLATFORM: Linux x86-64
      CLIENT_NAME: NASH01.SERVERFARM.CORNELL.EDU
       OWNER_NAME: 
 MOUNT_POINT_WAIT: 
 INPUT_MOUNT_WAIT: 
   INPUT_VOL_WAIT:  ,141013,225
 INPUT_VOL_ACCESS:  ,250152,740: ,/adsm7T20/T037,2678
OUTPUT_MOUNT_WAIT: 
  OUTPUT_VOL_WAIT: 
OUTPUT_VOL_ACCESS: 
        LAST_VERB: MediaMount
       VERB_STATE: Sent
   FAIL_OVER_MODE: No

Current mounted volumes includes:
11/16/2017 11:39:39   ANR8337I LTO volume 250152 mounted in drive DRIVE8503  
(/dev/rmt.e203.0.0). (SESSION: 179758)                   

Which is a copy storage pool volume.  Fortunately, we had drives available and 
the volume mounted so sys admin isn’t seeing a delay.

Not seen this before, not sure what the condition would be to have server reach 
to copy storage pool to get data.  

Has anyone seen/experienced this?

Thanks!



Robert Talda
EZ-Backup Systems Engineer
Cornell University
+1 607-255-8280
rpt4 AT cornell DOT edu