Scratch count

[alexsteele]

Hi All

we have few scratch volumes...so i was trying to delete the volumes which were in pending state which were reclaimed after reclamation process....after i delete the volumes its scratch count still remains the same, i have also tried updating the volume status to scratch after i delete the volume...need to know why the volume is not getting deleted or why scratch count is not increasing. Inputs appreciated

 

[moon-buddy]

Look at your 'reuse' setting - see 'q stgpool' and 'help update stgpool'

 

[ChrisRees]

Hi All

we have few scratch volumes...so i was trying to delete the volumes which were in pending state which were reclaimed after reclamation process....after i delete the volumes its scratch count still remains the same, i have also tried updating the volume status to scratch after i delete the volume...need to know why the volume is not getting deleted or why scratch count is not increasing. Inputs appreciated

What is shown in the actlog when you try and delete the volume or update its status to scratch? TSM probably won't let you do those operations on PENDING volumes.

You'll probably need to reduce the reusedelay parameter on the stgpool to get those tapes back to scratch.

Cheers

 

[sjl]

we have few scratch volumes...so i was trying to delete the volumes which were in pending state which were reclaimed after reclamation process....after i delete the volumes its scratch count still remains the same, i have also tried updating the volume status to scratch after i delete the volume...need to know why the volume is not getting deleted or why scratch count is not increasing. Inputs appreciated

You don't want to do that. If you delete volumes in a "pending" state, and subsequently need to restore a TSM database backup, you could very easily end up losing data. The reusedelay on all of your storage pools needs to be the same as, or longer than, your database backup retention period; deleting volumes that are pending means that it effectively isn't.

As a short-term thing, it can get you over the line, but if you're doing it long term, you're not resolving the fundamental issue, and you're exposing yourself to a world of potentially very serious pain.

As to the original query, we can't really comment on what the issue is without more detail - at the very least, activity logs for the period around the volume delete would be a start.

 

[sgabriel62]

yes change your reuse delay to 0 temporarily until you acquired your scratch back to the level you desire then set reuse to q value more manageable