Tiger22
ADSM.ORG Senior Member
I have a question about how TSM interacts with Virtual Tape Libraries when it returns VTL tapes to scratch.
Let's say I have a VTL that has been configured with 500 100GB tapes all of which have been checked into a VTL library within TSM. Let's say each night I perform a database backup to the VTL and a scratch tape from the VTL library is taken for this backup. At this point then the VTL knows about the data written to it and TSM knows that this VTL tape volume has a backup written to it.
After a few days, and after further and more recent database backups to additional VTL tapes have been performed, the older backup volume is returned by TSM to scratch. To my knowledge however the VTL is not informed of this and so considers the data on the tape that has been returned to scratch as still being 'in use'. By 'in use' I mean that the VTL is still using some of its disk space to store the data on this tape even though TSM has assigned its status back to scratch (after all the VTL has not been told that tape is no longer being used for valid data and will only know that when the tape is next written to by TSM).
Now the next time that TSM writes to this tape that it now considers as being scratch the VTL will free up the previous data it thought was being used. However this may be a long time in coming as TSM takes tapes from scratch in sequence. Potentially then there could be many dozen, if not hundreds, of VTL tapes that once had database backups on them that are supposedly now scratch but where precious disk storage is still being allocated by the VTL for them.
Does this sound right to everyone or is there some way of letting the VTL know from within TSM that it can release any disk storage it was once using for a particular VTL tape when it has been returned to scratch?
Of course this issue does not just apply to database backups but also to any process where TSM is moving (or expiring) previously written data from one tape and returning that tape to scratch on a VTL.
Let's say I have a VTL that has been configured with 500 100GB tapes all of which have been checked into a VTL library within TSM. Let's say each night I perform a database backup to the VTL and a scratch tape from the VTL library is taken for this backup. At this point then the VTL knows about the data written to it and TSM knows that this VTL tape volume has a backup written to it.
After a few days, and after further and more recent database backups to additional VTL tapes have been performed, the older backup volume is returned by TSM to scratch. To my knowledge however the VTL is not informed of this and so considers the data on the tape that has been returned to scratch as still being 'in use'. By 'in use' I mean that the VTL is still using some of its disk space to store the data on this tape even though TSM has assigned its status back to scratch (after all the VTL has not been told that tape is no longer being used for valid data and will only know that when the tape is next written to by TSM).
Now the next time that TSM writes to this tape that it now considers as being scratch the VTL will free up the previous data it thought was being used. However this may be a long time in coming as TSM takes tapes from scratch in sequence. Potentially then there could be many dozen, if not hundreds, of VTL tapes that once had database backups on them that are supposedly now scratch but where precious disk storage is still being allocated by the VTL for them.
Does this sound right to everyone or is there some way of letting the VTL know from within TSM that it can release any disk storage it was once using for a particular VTL tape when it has been returned to scratch?
Of course this issue does not just apply to database backups but also to any process where TSM is moving (or expiring) previously written data from one tape and returning that tape to scratch on a VTL.
