Overview
Overhead on tapes can be considered as the difference between the anticipated and actual tape usage for the writing of a known quantity of data. In simpler terms, it's the space lost during the write process—typically caused by “soft retries,” where the drive reattempts writing due to suboptimal conditions.
Causes
Unlike sealed hard disks, tape drives are exposed to environmental factors like dust and contaminants which can affect the quality of writing. During the write process, the drive uses a read-after-write head to verify data integrity. If the verification fails for a block of data, the drive automatically rewrites the block.. Excessive rewrites sometimes due to a dirty or failing drive—consume additional tape space, potentially preventing the tape from reaching its full rated capacity.
This becomes especially problematic with replica tapes. If overhead is too high, the system may be unable to fit all the data onto the replica that was successfully written to the primary. This can trigger an alert when the tape or partition reaches its end. XenData Archive Series software allows up to 2% overhead by default. XenData support can increase the overhead allowance if needed.
Identifying which drive is causing the overhead can be tricky in multi-drive setups, XenData support can assist in pinpointing the culprit.
Solutions
Step 1: Clean the Drive Start by cleaning the affected drive. If overhead persists, escalate to the library provider. They’ll usually request a service dump, which helps identify high write retry counts and may justify a drive replacement.
Step 2: Resolve the Alert You have two options to address the overhead alert for replicated tape volumes:
1. Export and Forget the faulty replica
Remove the replica with high overhead and create a new one. This is the preferred method—it uses only two drives, copying from the primary to a fresh replica.
2. Repack the Volume
Repacking involves reading from one tape and writing to two others, which can cause frequent tape swaps in a two-drive library. To minimize disruption, set replication to “scheduled” during the repack process.