I see this strange behavior as well. All the tapes are READWRITE and FILLING. It's the same on TSM V5 or V6.
Sometimes this arises when you have multiple migration processes. A guess is that you will have (migprocesses * collocationgroups) FILLING tapes. That could be a lot of FILLING tapes. But in real life, there are often more than (migprocess * collocationgroups) FILLING tapes. I think this can also come about due to tape thrashing as migration works its way through collocation groups. If you have two tape drives, and the FILLING tape for a collocation group is in use on one, but the second migration process wants to use that tape to migrate files for another node in that same collocation group, it allocates a new scratch tape. So one change I'd suggest for TSM development would be to migrate all nodes in a collocation group together. This would improve both tape utilization, and performance. Even that does not explain it all. I still see scratach tapes allocated when there are FILLING READWRITE tapes available for the same collocation group. It is still strange. If the number of scratch tapes is getting low, I MOVE DATA off of the 1% full volumes. There is so little data involved in a 1% full tape, that you can typically afford to move it back into a disk stgpool where it will be re-migrated. I wish it didn't work this way, but I don't worry about it too much. The 99% empty FILLING tapes will be used as soon as really needed. I start to worry when I see that the situation is forcing the server to ignore collocation boundaries. That can happen when the number of scratch tapes reaches 0. Pay more attention to setting MAXSCRATCH to the actual number of tapes in your tape library, and to setting ESTCAP in the devclass to how much data you can actually put on a tape after compression, and then your %full statistics will accurately reflect the total amount of unused space left in the stgpool on FILLING tapes as well as SCRATCH tapes. Our real-life compression ratio runs about 1.4:1. This annoying but not critical problem is even worse with FILE stgpools. Another reason we use scratch FILE volumes, not preallocated ones. A 1% full scratch FILE volume only takes up 1% of the space, whereas a 1% full preallocated volume (like a tape) takes up 100% of the space. Roger Deschner University of Illinois at Chicago rog...@uic.edu ======I have not lost my mind -- it is backed up on tape somewhere.===== On Thu, 19 Sep 2013, Lee, Gary wrote: >A few were readonly. However, that did not explain all of them by a long way. >Others are filling. > >-----Original Message----- >From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of >Prather, Wanda >Sent: Thursday, September 19, 2013 4:05 PM >To: ADSM-L@VM.MARIST.EDU >Subject: Re: [ADSM-L] strange tape handling > >What is the access setting on the tape, is it READWRITE? And is status FULL or >FILLING? > >-----Original Message----- >From: ADSM: Dist Stor Manager [mailto:ADSM-L@VM.MARIST.EDU] On Behalf Of Lee, >Gary >Sent: Thursday, September 19, 2013 2:05 PM >To: ADSM-L@VM.MARIST.EDU >Subject: [ADSM-L] strange tape handling > >Tsm server 6.2.4 on RHEL 6 > >Tape storage pool on ts1120 tapes, collocation set to group. > >Node libprint does not belong to any group. Its data is now on two volumes. >First volume has estimated capacity 1 tB. >It is 1.4% full. > >This morning, tsm was migrating its data from disk pool to tape. It pulled >another scratch to store systemstate data even though the original volume was >only 1.4% full as stated above. > >What is up with this. This is causing my scratch tapes to be eaten up to no >purpose. >
