Tape shoe-shining: how much a backhitch costs, what speed matching removes, and what the logs do not show
Published 2026-10-11
A backhitch is a full stop, reverse and restart of the tape, and the two IBM patents opened for this page both put it at about 2 to 3 seconds, during which nothing is written; repeated backhitching is the 'shoe-shining' pattern. Drives avoid it by speed matching: IBM lists 12 native speeds from 177 to 408 MB/s for LTO-9 media on full-height drives (the lowest is 43% of the highest) and 112 to 365 MB/s for LTO-8 media, HPE states a 100 to 300 MB/s native range for its half-height LTO-9 drive, and Oracle's T10000D runs at five discrete tape speeds from 2.75 to 4.75 m/s. A host that stays below the lowest matched speed cannot be matched, so the drive must stop and reposition whenever its buffer (1,024 MB on the IBM and HPE LTO-9 drives) runs dry. Vendors say this wears drive and media, but none of the opened sources publishes a measured wear rate, a backhitch count per cartridge life, or a TapeAlert flag or log counter that reports backhitches, so the effect is documented as a mechanism and a design goal, not as a measured failure rate.
- Event
- Backhitch: tape stops, reverses and restarts; both IBM patents give about 2 to 3 seconds per event, with no writing during it.
- Main remedy
- Speed matching: 12 listed native speeds, 177 to 408 MB/s (IBM, LTO-9 media, full height); 100 to 300 MB/s native (HPE, LTO-9 half height).
- Buffer
- 1,024 MB on IBM and HPE LTO-9 drives; 256 MB on T10000A/B and 2 GB on T10000C/D (Oracle).
- Not covered
- Measured wear per backhitch, field failure rates, optical media, and any recovery of damaged tape.
How far down speed matching can follow a slow host
| Drive and media | Highest listed native rate (MB/s) | Lowest listed native rate (MB/s) | Lowest as share of highest (%, computed) | Cross-check (second source) | Source |
|---|---|---|---|---|---|
| IBM Ultrium, generation 9 media, full height | 408 (IBM states a 400 maximum) | 177 | 43.4 | HPE lists 100 MB/s as the lowest for its LTO-9 drive, which is lower | IBM speed matching page |
| IBM Ultrium, generation 8 media, full height | 365.0 | 112.0 | 30.7 | HPE LTO-8 drive: 100 to 300 MB/s native | IBM speed matching page |
| IBM Ultrium, generation 7 media | 306.0 | 101.46 | 33.2 | HPE LTO-7 drive: 100 to 300 MB/s native | IBM speed matching page |
| HPE LTO-9 Ultrium 45000, half height | 300 | 100 | 33.3 | IBM LTO-9 media floor is 177 MB/s; the sources do not explain the difference | HPE LTO QuickSpecs |
| Oracle StorageTek T10000D (tape speed, not data rate) | 4.75 m/s | 2.75 m/s (speeds: 4.75, 4.25, 3.75, 3.25, 2.75) | 57.9 | Oracle also lists T10000A at two speeds, 2.0 and 4.95 m/s | Oracle T10000 guide |
What one backhitch costs, and how long the buffer lasts
| Quantity | Unit | Value | Basis | Cross-check (second source) | Source |
|---|---|---|---|---|---|
| Backhitch duration | seconds (s) | about 2 to 3 | Patent background text: 'approximately two to three seconds' | US 8,035,912 gives 'approximately three seconds' in its worked example | US 9,251,840 |
| Streaming time lost per backhitch at 400 MB/s (IBM LTO-9 full height) | megabytes (MB) | 800 to 1,200 (computed) | 2 to 3 s multiplied by 400 MB/s | IBM position paper gives the 400 MB/s maximum | IBM LTO 9 position paper |
| Streaming time lost per backhitch at 300 MB/s (HPE LTO-9 half height) | megabytes (MB) | 600 to 900 (computed) | 2 to 3 s multiplied by 300 MB/s | HPE lists 300 MB/s sustained native | HPE LTO QuickSpecs |
| Time to empty a full 1,024 MB buffer at 300 MB/s (HPE LTO-9) | seconds (s) | 3.4 (computed) | 1,024 MB divided by 300 MB/s | IBM LTO-9 also lists a 1,024 MB cache | HPE LTO QuickSpecs |
| Time to empty a full buffer at 252 MB/s (Oracle T10000C/D, 2 GB) | seconds (s) | about 8.1 (computed) | 2,048 MB divided by 252 MB/s | Oracle lists the 2 GB buffer and 252 MB/s native sustained rate | Oracle T10000 guide |
| Time to empty a full buffer at 120 MB/s (Oracle T10000A/B, 256 MB) | seconds (s) | about 2.1 (computed) | 256 MB divided by 120 MB/s | Oracle lists the 256 MB buffer and 120 MB/s rate | Oracle T10000 guide |
Causes of backhitching and what each source says about visibility
| Cause | What the source says | Not provided in the source | Cross-check (second source) | Source |
|---|---|---|---|---|
| Host slower than the lowest matched speed (buffer runs dry) | IBM: a backhitch 'is usually the result of a mismatch between the data rates of the server and the drive'; HPE: matching 'minimizes rewinding and repositioning of the tape, reducing wear' | A count of backhitches, or a threshold in MB/s at which they begin on a given host | IBM patent 8,035,912: a backhitch occurs 'when the buffer runs out of data' | IBM speed matching page |
| Host sync commands (tape mark or flush) | Oracle: writing a tape mark or other sync 'normally' causes back hitches; its File Sync Accelerator is on by default and its Tape Application Accelerator is off by default | How many syncs per hour a given backup product issues | IBM position paper lists a 'SkipSync' function for small-file backhitchless flush; IBM patent 8,035,912 describes backhitchless flush | Oracle T10000 guide |
| Position error too large (stop-write events) | IBM patent 9,251,840: when position error stays over the stop-write limit the drive must stop writing and reposition; causes named: media damage, drive damage, debris | How many stop-write events a healthy tape has; the patent's example graph has a vertical axis without units | IBM patent 8,035,912 lists error-rate history as one input to the decision to avoid backhitching | US 9,251,840 |
| Deferred errors after buffered tape marks | Oracle: with buffered tape marks 'a deferred error may be reported' after the command completed, so a tape mark no longer confirms the data reached tape | Whether other vendors' drives behave the same way when sync is skipped | IBM patent 8,035,912: backhitchless writing trades capacity for speed and is gated by remaining capacity, error rate and count | Oracle T10000 guide |
| Capacity cost of avoiding a backhitch | IBM patent 8,035,912: skipping the reverse leaves a gap on tape; example margin of 7%, so a 500 GB tape could hold 535 GB at a very low error rate | Real gap size per drive or the margin of any shipping cartridge | Oracle: 'Maximum Capacity' feature is off by default and gives 5.5 TB on T10000C (5 TB native) | US 8,035,912 |
Reading the numbers
The cost of one backhitch is time first. Both IBM patents put it at about 2 to 3 seconds, with writing blocked until it is done. At the highest native rates in the opened tables that is 800 to 1,200 MB of streaming time on an IBM LTO-9 full-height drive and 600 to 900 MB on an HPE half-height drive. These are computed products of a patent's rounded duration and a datasheet rate, not measurements from a drive, and both patents come from the same company.
Speed matching works down to a floor, and the floors are published. IBM's table runs from 177 to 408 MB/s for LTO-9 media (43% of the top rate) and 112 to 365 MB/s for LTO-8 media (31%); HPE gives 100 to 300 MB/s for LTO-7, LTO-8 and LTO-9 half-height drives (33%). A host that cannot sustain the lowest value leaves the drive to wait, stop and reposition. The IBM and HPE LTO-9 floors differ (177 against 100 MB/s native) and the sources do not say why, so the number a given host must reach depends on whose drive and which media are in use.
The buffer sets how long a stall can be absorbed. A full 1,024 MB buffer empties in about 3.4 seconds at 300 MB/s, and Oracle's 2 GB buffer in about 8.1 seconds at 252 MB/s (both computed). How long a stall the buffer can hide therefore depends on the drive rate, and the sources do not say how long host stalls typically last.
What the logs show is the weak point. HPE and IBM state that speed matching reduces wear, and the IBM patent says excessive backhitching wears drive and media, but none of the six opened documents gives a wear figure, a count of backhitches that a cartridge or head tolerates, or a status flag for backhitching. The ten TapeAlert flags tabulated on the companion page cover media, read and write faults, mechanical faults, cleaning and self-test, and none is a repositioning flag, although that table shows only ten of the 64 flags. A drive that backhitches constantly can therefore look healthy until errors appear, and the only direct evidence of the pattern in these sources is the drive's own throughput.
Avoiding the stop has its own trade-offs, and the sources name them. IBM's patent describes writing on without reversing at the cost of tape capacity (a 7% margin in its example) and gates that on remaining capacity, error rate and count. Oracle's accelerators remove sync-induced backhitches but, with buffered tape marks, a deferred error can surface after a command has already completed. These are design choices, and the opened sources do not measure how often they are used.
What this page does not contain is a field study. No public dataset opened for this page links backhitch counts to cartridge or drive failures, so 'shoe-shining damages tape' stays a vendor-stated mechanism with unmeasured size.
Related: the LTO TapeAlert note,the SCSI sense and kernel-log note and what fails most often on HDDs, SSDs and links.
Method
Everything on this page was read on 2026-10-11 from documents opened that day: IBM Documentation's 'Speed matching' page for IBM Ultrium drives; the IBM LTO 9 full-height performance position paper (October 2020); the HPE LTO Ultrium QuickSpecs (September 2025 copy hosted by a reseller, read as a PDF); Oracle's StorageTek T10000 Systems Assurance Guide introduction chapter; and two IBM patents read in full on Google Patents, US 8,035,912 B2 (Katagiri and Oe, granted 2011) and US 9,251,840 B2 (Bui et al., granted 2016). The three vendors (IBM, HPE, Oracle) are independent of each other; the three IBM documents are not independent of one another. Values are copied as printed; values marked 'computed' are ratios or products derived on this page from printed values. No drive was run and no log was captured for this page.
Limits
No source opened for this page measures wear caused by backhitching: HPE says speed matching 'reduces wear and increases reliability' and the IBM patent says excessive backhitching 'wears both the magnetic tape drive and the magnetic tape data storage media', but neither gives a number of backhitches per cartridge, a change in error rate or a failure count, so the wear effect is a vendor statement. The 2 to 3 second figure comes from patent background text, not from a drive specification, and both patents are IBM's. The speed tables are vendor specifications, not field measurements, and the two LTO-9 floors disagree (IBM 177 MB/s native on its listed LTO-9 media speeds, HPE 100 MB/s for its LTO-9 drive); the sources do not say why, and the IBM page lists 12 speeds where the IBM position paper says full-height LTO-9 uses 14, and its top listed speed (408 MB/s) is above the stated 400 MB/s maximum, so the table is quoted as printed. The Oracle figures are for T10000 drives, which are not LTO. The patent examples (a 7% capacity margin on a 500 GB tape, a 0.35 micrometre target for position error spread) are illustrative values inside patent text, not product specifications. No public log line or counter for backhitches was found in the opened sources; absence from these six documents is not proof that none exists. The page covers drive behaviour and status signals only: nothing here concerns encrypted cartridges, recovery from damaged tape or anyone else's media.
Sources
- 01IBM Documentation: Speed matching (IBM Ultrium tape drives) · accessed 2026-10-11
- 02IBM LTO 9 Tape Drive Full Height Model Performance Position Paper (October 2020) · accessed 2026-10-11
- 03HPE Storage LTO Ultrium Tape Drives QuickSpecs (September 2025 copy, PDF) · accessed 2026-10-11
- 04Oracle StorageTek T10000 Tape Drive Systems Assurance Guide: 1 Introduction · accessed 2026-10-11
- 05US 8,035,912 B2: System and method for controlling traveling of tape (IBM; Katagiri, Oe) · accessed 2026-10-11
- 06US 9,251,840 B2: Dynamically controlling tape velocity (IBM; Bui et al.) · accessed 2026-10-11