TSM Not reclaiming tapes

[Doug4711]

First I'm Still a newbie here but...

We have tsm running with an IMB3573 tape library

For the nearly the last two weeks, our backup set has got larger

There are tapes in the set which are as low as 2.3% utilized infact about 10 tapes are utilized low enough to be reclaimed.

The reclaim is run every day against the pool and seemed to work fine until about last week some time.

I modified the maintenance script to bring the % down from 50% to 40%

reclaim stgpool LTO4POOL threshold=40 wait=yes
reclaim stgpool COPYPOOL threshold=40 wait=yes

But still nothing has been reclaimed and we are slowly running out of scratch tapes

Any ideas guys

 

[max]

hi,

you can check which volumes are eligible for reclamation with the following command

select volume_name, pct_reclaim, stgpool_name from volumes where pct_reclaim>=50 order by 3,2 asc

but most of all i'd never run reclamation under 60%.
If your volumes are eligible for reclamation but the process does not start, you should check why into the actlog, as tsm server would produce some errors and warnings about that.

cheers
max

 

[icewalker]

That is a bit odd. Check your stgpool reclamation thresholds and make sure they are not set to 100. I've never actually ran a manual reclaim stgpool command before.

q stg lto4pool f=d
q stg copypool f=d

Look in the output for the following (my copypool1 looks like this):

Reclamation Threshold: 100

I would agree that I would never set my reclamation for my primary pool below 60 but that is definitely personal preference. As for your copypool storage, if you have the tapes to spare, up the reclamation threshhold. That will help you from moving so many tapes back and forth from your offsite facility. I periodically adjust my copypool1 reclamation to bring back tapes like so:

update stg copypool reclaim=90

Which kicks off a space reclamation automatically if I have tapes to reclaim. I use the following SQL statement to get a good picture of my pools.

select volumes.volume_name as "VOLUME_NAME", volumes.stgpool_name as "STGPOOL_NAME", volumes.pct_reclaim as "PCT_RECLAIM" from volumes where STGPOOL_NAME = 'COPYPOOL1' order by pct_reclaim

Good Luck

 

[mateinone]

There are tapes in the set which are as low as 2.3% utilized infact about 10 tapes are utilized low enough to be reclaimed.

The % utilized is not the issue, the % reclaim is what you should be looking at.

select count(*) from volumes where pct_reclaim>=50

etc etc to see the volumes that are reclaimable.

Are you collocating by node?

 

[ypcat]

Reclamation is a funny thing. To clean up a bit you should start small:

update stg [storagepoolname] reclaim=95

Then after that is done, go 5 more percent

update stg [storagepoolname] reclaim=90

then 85, etc.

This will get your scratch volumes back faster and after that you can set the script to run as per normal; 60% is a good normal. If reclamation is running too long or you are short on scratch and want to free some up quickly you can set 2 or more scripts to run as per above; do the quick ones first and work your way down to 50%.

 

[n9hmg]

If your reclamation fails, you may have to do a "move data" on the volumes it says it can't do. I've blathered on for several pages on this subject in http://adsm.org/forum/showthread.php?p=51785

 

[Doug4711]

Issue may now be solved??

I checked to see if there was any spanning of files accross volumes - None

I looked at the % reclaimable space on each of the vols in question - Was above the threshold so no luck there

We decided to re-boot the server and try one of your recommendataions - to update the storage pool reclaim to 60%.

Over the weekend more than 12 tapes were marked as pending so one of those must have fixed it

Many thanks guys

Doug

 

[pstacy]

Going back to post #5 here, is there a way to check all the tapes at once for ones with content spanning multiple tapes? My TAPEPOOL group has many tapes in it and it could take awhile to check each one by one.

 

[Shhyam]

can we check using sql query to find in which volumes the 1/2 and 2/2 the files are spanned .

 

[ramzeso]

Hi there, I have got problem with reclamation too.

I run reclaim for pool called serverstape, and I noticed that durring reclaimation on one tape pct_reclamilable was increasing why?
And also I have noticed that reclaimation process created volumes on my diskpool. Can someone explain why? How this reclaimation works? For tapes and for disk pools?

 

[TiborB]

as you can see (f.e. with 'select * from volumes') PCT_UTILIZED+ PCT_RECLAIM=100%, so when you are moving data from your tape, utilization goes down, free (reclaimable) space goes up. So you obviously mis-understand what PCT_RECLAIM is to mean.

As for second question - I would say there was some other reason why the volumes were created. You can try 'q actlog search=volumename begindate=-1' as a starting point of your investigation...

 

[ramzeso]

I run command to see volomues which are eligible to reclamation. As you can see reclamation threshold is set on 50



here also q vol command. Problem is with reclamation. When I run reclamation, here is error, still don't know why.
And what i want, is to remove some of dedup volumes (cuz as we can see, data is spreed on many volumes)

 

[SniperKing]

Hi ramzeso,

If you set the reclaim threshold at staging pool level, it will trigger every hour and look for reclaim of data that is under threshold

 

[TiborB]

Well, it seems that max scratch limit is achieved (20 used=20 as limit). You should increase the parameter at least by one.

 

[ramzeso]

Well, it seems that max scratch limit is achieved (20 used=20 as limit). You should increase the parameter at least by one.

Ok i got, but when I increase max scratch lvl, and run reclamation, will some of my volumes dissappear?

EDIT, I increased by 1 and run reclaim stg dedup - the same error.

 

[TiborB]

the result would be much smaller number of volumes in storage pool, the empty volumes will be changed to 'scratch' and be available for other use...

As for the problem... I dont know, but did you tried like

move data $SOMEVOLUME

it will move a data from one volume to another volume within the same storage pool

 

[ramzeso]

It didn't help me so much.

 

[TiborB]

Did you try to 'move data'? What was the result?

 

[ramzeso]

Here is result.

 

[TiborB]

well, look at actlog 'q actlog' to check that any move data took place. Or during moving, you can use 'q pr' to see that data move is taking place and actual data are moved....

however, now I can see that some of your tapes are in filling status, that means the lack of scratch tape was not the issue....