Volume usage pequliarity

[sandragon]

I've started to notice, and had to fight, an oddity with TSM and how it uses volumes, especially LTO tape.

I inherited this system from a previous admin so if I'm missing a parameter anywhere, I'd love to know.

What I'm observing is this. If a storage pool (primary or secondary) has multiple volumes that are in 'filling' status, it will not use another volume that's only partially utilized when it hits End of Volume. Instead, it will ignore the partially filled tapes and grab a new one from the scratch pool. This has often lead to situations where, for some pools, despite only having 1 migration process from disk to tape there are 6-10 'filling' volumes. Since TSM prefers to use the most utilized volume first, nine times out of ten I'll end up with multiple low usage volumes at 1-5%, and one or two high usage volumes. I'm not sure what's causing the extra volumes to drop into the pool in the first place, but once they're there, the problem quickly grows out of control until I am out of scratch and have a large number of underutilized volumes.

I've been having to go through and manually consolidate these down with a move data command.

What I hope to find is that there is a way to tell TSM that instead of grabbing a fresh scratch tape, it should continue its write on a partially utilized volume already within the storage pool, if it is available. Any way to make that happen?

TSM 7.1.1.100 on AIX 7.1.

 

[marclant]

That's how TSM works, picks a filling tape first, then writes to scratch. See here: http://www-01.ibm.com/support/knowl...m.itsm.srv.doc/c_colloc_disabled.html?lang=en

Also, do you use collocation? If so, then that will also cause more filling volumes (1 per node or 1 per group depending on config), see here: http://www-01.ibm.com/support/knowl...bm.itsm.srv.doc/c_colloc_enabled.html?lang=en

 

[sandragon]

The previous admin had left colocation=group on but not defined any groups, so we were wasting a huge amount of tape space. I disabled collocation due to our space issues. We're at physical capacity, so every inch of Mylar I can put data on is needed. It would be nice if it would pick subsequent filling tapes instead of taking one, then grabbing a scratch to create yet another.

Looking at your first linked document... using their diagram, my condition is that tapes 3, 4, and 5 all have a little data on them... so TSM grabs tape 3, fills it, then starts working on a brand new tape 6 instead of filling 4 and 5. That's where my frustation is coming from. This document seems to indicate it would keep grabbing partially used, filling tapes if present. That's not the behavior I'm seeing.

 

[marclant]

Collocation by group with no group members is essentially collocation by node. So if a node is doing a backup or the server is migrating from disk to tape, it will pick a filling tape for that node, then pick a scratch, if the other filling tapes are not for that node, it will take another scratch.

Now that you disabled collocation, it should behave a bit differently. Reclamation may reclaim some of the space too because now it can store data from multiple nodes on a tape.

 

[sandragon]

Collocation has been disabled for over a year now but it continues to behave as I have been describing. If I have tapes 01, 02, and 03 at 10%, 20%c and 2% utilization respectively... TSM will fill tape 02, then ignore tapes 01 and 03 all together for the rest of the migration job and grab a scratch tape 04 once 02 is full and start filling it instead. Only a new migration process where 01 or 03 happens to be the 'most utilized' filling tape will touch them.

 

[smajl]

Hi sandragon.
Volume utilization is only average value, maximum volume "size" depends on compression ratio of data stored on the date, ie LTO-4 tape can store from 0.9 TB to 3.2 TB. Due to this TSM server cannot predict how much free space is on tape and rather grabs scratch tape instead of folowing:
If you consider following situation:
4 filling tapes: vol1 with 20 GB free space, vol2 with 10 GB free space, vol3 with 200 GB free space, vol4 with 500 GB free space. Some big file being backed up (400GB).
-> vol1 is chosen as destination.
-> only 20 GB of data can be stored on the tape. A message can be observed in actlog: ANR8341I End-of-volume reached for LTO volume vol1
-> vol2 would be chosen as next tape
-> only 10 GB of data will be saved due to End-of-tape condition.
-> vol3 is chosen
-> another 200 GB of data will be saved until End-of-tape condition.
-> vol4 is chosen
-> rest of file finally saved.
You end up with one file stored on 4 (or more) tapes, for restore the file TSM needs to mount many times