Does reclamation work for all copygroup version values?

[ldmwndletsm]

Not sure how to word this question. If you have 'No Limit' set for the four values (verexists , verdeleted, retextra, retonly) in the copygroup, then could reclamation ever occur under any circumstances?

For example, I thought if you had a reclamation threshold for the storage pool set to, say, 50% then when TSM determines that 50% of the data on a given tape volume no longer lives on the client's disk then it will reclaim the tape. But wouldn't the caveat be that the affected files have expired in the database, or they are no longer bound to the four limiting values defined in the copygroup? Wouldn't that condition still have to be met for reclamation to occur on tapes in that storage pool?

 

[marclant]

Reclamation doesn't care about copy groups and/or retention. It also doesn't care about "Percent Used".

It only cares about one thing and it's "Percent Reclaimable", which is the percent of free space between the start of the tape and the last file on the tape.

 

[marclant]

To add on my previous comments, Expiration removes files based on retention, that causes the empty space in between files that reclamation can reclaim. Also, if you keep X versions, and a client backs up X+1 versions, the oldest is expired immediately which causes space in between the remaining files. All that space is reclaimable space.

 

[ldmwndletsm]

Right. I think I phrased the question incorrectly then. Or at least I'm trying to ensure that I'm not missing something critical here. Perhaps the better question is how could empty space ever occur if you have 'No Limit' set from the get-go? Clearly, in that case (albeit, a very special one), every object backed up would remain in the database for perpetuity, so TSM could not in good faith recycle (unless you forced it to?) any tape in the storage pool; otherwise, the idea of unlimited versions would be meaningless. So it could never say: "Gee, I see that 50% of the files on this tape have expired so I'm going to copy all the other non-expired data to another tape and then free this tape up to the scratch pool." Or rather, it would never reach that conclusion, even if you set it to 1%, since 'No Limit' would allow you to always recover, at least as long as you still have the tape.

That being the case, then reclamation could never occur, no mater what percent you set it to, since there would never be any empty space, even following the deletion of a file from disk, since 'No Limit' would force the database to track every version ever sent. That right?

Oh my, please tell me this is correct and that there isn't some other way that reclamation could subsequently occur naturally (Yikes!) UNLESS you did something manually (like changing some of those four values), or you deleted a volume or deleted a file space or something like that, i.e. taking some overt action to bring it about?

Anyway, it's better to be wrong here on this forum than on the interstate.

 

[marclant]

Reclamation doesn't create empty space, it just reclaims it if it becomes reclaimable space. That's all handled by expiration. So expiration will only delete objects from the database that exceeds the retention policy.

Now, the "no limit" would have to be on everything, verexist, verdeleted, retextra and retonly. Otherwise, it's still possible to have data expire if it meets one of the criteria.

 

[RecoveryOne]

Here's a really handy doc to explain how retention comes into play:
https://www.ibm.com/support/knowled...bm.itsm.srv.doc/r_mplmntpol_retbackpvers.html

Gives multiple examples of how NOLIMIT comes into play and which controls what.

 

[ldmwndletsm]

Thanks, all. That pretty much answers it. And, yes, the "no limit" is on everything in this case. That's a very useful document. I remember reading about this in pieces here and there, but I don't know that I saw that one. Appreciate it.

By the way, if you had, for example, a couple of file spaces that were on their own tapes, and nothing else was on those tapes, and those file spaces were only on those tapes, and those tapes had their status set to read-only and you wanted to reuse those tapes, and you then deleted those file spaces then I would expect that TSM would remove all those objects from its database, and then the "no limit" setting wouldn't matter in that case, right? Those tapes would then be available to be returned to the scratch pool once the REUsedelay (10 days in this case) expired. That right? Is this an example wherein you're forcing the expiration to occur?