I've been going over logs of tape mounts, looking for a tape performance issue. I watched the tape library for a while during migration, and the robot was being kept very busy, mounting and dismounting the same set of tapes over and over. When each tape volume is mounted and dismounted as many as 6 times during a single migration, something is not right. Not only is this rather slow, but it is wearing out the tapes.
Group collocation is set for both the DEVTYPE=FILE disk stgpool, and the next one in the heirarchy which is tape. The collocation groups are sensibly-sized - total size of each group is about (capacity of one tape * number of tape drives), to optimize large restores. However, I'm seeing this tape thrashing as migration proceeds. Why is this happening with the same collocation in effect for both stgpools? Shouldn't migration be optimized for tape mounts when the collocation definitions are the same? BTW, I looked over the tape mounts for a different server which migrates from DEVCLASS=DISK (random, no collocation) to tape, and I saw the same effect, though not quite as bad as DEVTYPE=FILE (sequential, group collocation) to tape. I have set MAXCAP on the devclass to 25gb. Would making that larger help? I'm not sure it would, since the random-access stgpool acted mostly the same way. This is TSM 6.2 on AIX, with LTO-4 and LTO-5 tape. Roger Deschner University of Illinois at Chicago [email protected] ======I have not lost my mind -- it is backed up on tape somewhere.=====
