VTL - Deduplication failing with error "the max number of dedups on a tape is exceeded"

Asset ID:	1-72-1351561.1
Update Date:	2011-12-01
Keywords:

Solution Type Problem Resolution Sure

Solution 1351561.1 : VTL - Deduplication failing with error "the max number of dedups on a tape is exceeded"

Applies to:

Sun StorageTek VTL Prime System - Version: 1.0 - Build 1813 to 1.1 - Build 2076 - Release: 1.0 to 1.0
Oracle Solaris on x86-64 (64-bit)

Symptoms

Deduplication failing
Dedup Scan failing
The following are example messages you may see in message file (same error two days in a row):

May 27 09:01:55 vtlbg VTS: [ID 702911 daemon.notice] IPSTOR||1274943715||E||0x0000c615||SIR Scanner: Tape %1 scan failed in Drive %2; Reason is %3||00VBG056||964Q400205||the max number of SIR folders is exceeded
May 27 09:02:26 vtlbg ipstorcomm: [ID 702911 daemon.notice] IPSTOR||1274943746||E||0x0000c554||Policy %1, Tape [%2] scan process terminated with error: %3.||VTLBG_all||00VBG056||the max number of dedups on a tape is exceeded

...

May 28 09:01:59 vtlbg VTS: [ID 702911 daemon.notice] IPSTOR||1275030119||E||0x0000c615||SIR Scanner: Tape %1 scan failed in Drive %2; Reason is %3||00VBG056||964Q400203||the max number of SIR folders is exceeded
May 28 09:02:27 vtlbg ipstorcomm: [ID 702911 daemon.notice] IPSTOR||1275030147||E||0x0000c554||Policy %1, Tape [%2] scan process terminated with error: %3.||VTLBG_all||00VBG056||the max number of dedups on a tape is exceeded

Cause

This message is self explanatory. There is a 128 limitation on how many times a tape can dedupe. If virtual tapes have been deduped so many times that it has exceeded the 128 limitation and can no longer be deduped.

Solution

To continue deduping these virtual tapes, we recommend them to do the following:

To "reset" dedup limit:

Copy out all of the data from this tape and move it to a new tape.
This can be done via backup application or via local replication.
Then delete the old virtual tape.
Note: If scheduled reclamation policies don't clean up deleted virtual tape, may have to manually reclaim SIR space and prune SIR index.

To limit the possibility of limit being reached again:

Move any dedupe tapes that the are dedup'd at high rate into a new dedup policy and set the policy to dedup via schedule or manually triggered.
This will limit the times dedup will kick off on the tapes and decreasing the chances of a tape ever hitting the 128 mark.

Misc notes:

In the Xray under the conf/<servername> directory, there is a vtlrde.conf file that shows the dedupe policies sent and what tapes goes to which policy.
And in file SIRScannerLog.csv, you can find the number of times a virtual tape had been successfully deduped, and information was written to the repository. This can be used to see if any other tapes are getting close to limit and should have a different policy (There were also instances of where no data had been written as the result of the scan, so these would not be included in the count of 128).

Attachments

This solution has no attachment