Sample Tape Drive I/O with tapestat

tapestat samples read and write activity on a Linux tape drive, and its first report can lie to you if you let it. This walks through a repeatable sampling routine, what the columns actually mean, and why a wait percentage over 100 is not automatically a broken drive. The examples use tapestat from sysstat 12.6.1, installed here as package version 12.6.1-2.

Allow about ten minutes. You need a shell, the sysstat package, and a tape drive whose kernel statistics are available. This guide only reads statistics: it does not rewind, mount, unload or write to a tape, and normally needs no elevated privileges.

1. Check the installed command

Start by confirming which executable will run, and record its version:

$ command -v tapestat
/usr/bin/tapestat
$ tapestat -V
sysstat version 12.6.1
(C) Sebastien Godard (sysstat <at> orange.fr)

The manual page on this system is dated June 2020, while the installed sysstat package is 12.6.1-2; keep that version in an incident note when comparing output from another host. The command needs a kernel with tape statistics support, normally 4.2 or later, and /sys must be mounted.

Checkpoint: If command -v finds nothing, install or enable the package through your normal operating-system process. Do not copy a binary from another host just to make the check pass.

2. Take one current sample

Run a one-second sample and ask for one report:

$ tapestat -y 1 1

The -y option omits the initial report, which would otherwise cover activity since boot. The trailing 1 1 means one report at one-second intervals, useful for a quick check because it avoids mixing long-running historical activity into the measurement you actually asked for.

On a machine with no eligible tape drive, the command can finish with:

No tape drives with statistics found

That is a real result, not a blank report: it means there is no tape device with statistics for tapestat to display. If a drive is expected, check the host, the attached hardware and the kernel interfaces before you interpret any throughput.

With a recognised drive, expect a header followed by a row per tape device. The header includes the hostname, date and architecture, and the device name depends on the host. Do not paste a sample row into a capacity calculation without checking its interval and units first.

3. Understand the report columns

The useful fields all describe the average over the sample interval:

The wait columns are not capped at 100 in the underlying timing model. A long operation can finish after the interval it started in: a 40-second rewind observed with a five-second interval can show near-zero wait in earlier reports, then roughly 800 percent when it completes. tapestat displays nothing above 999, but a value above 100 is not automatically corrupt.

4. Monitor a drive for a fixed period

For a short live view, omit the count. This samples every five seconds until you stop it:

$ tapestat -y -t -m 5

Here -t adds timestamps, -m reports rates in mebibytes per second, and 5 is the interval. Press Ctrl-C to stop the continuous report; stopping the display does not stop tape I/O or touch the drive, it only ends tapestat.

For a bounded capture, add a count:

$ tapestat -y -t -m 5 12

This asks for twelve reports, five seconds apart, which is useful when collecting evidence for a backup run so the command exits by itself. The first report is still omitted by -y; without that option, the first report represents the period since boot and only the following reports represent the intervals between samples.

Checkpoint: Write down the interval and count beside any copied output. A row labelled "per second" is only meaningful once its sampling period is known.

5. Reduce noise from idle drives

If several drives are attached but only one is active, add -z:

$ tapestat -y -z 10 6

This omits tapes with no activity during the sample period. It is convenient on a busy host, but an absent row does not prove the drive is disconnected: it may simply have been idle for those ten seconds. Remove -z when you need to confirm which recognised drives exist at all.

Choose either -k or -m when you need an explicit fixed unit; they are mutually exclusive. --human uses readable units such as 1.0k or 1.2M and takes precedence over the other unit defaults. Avoid mixing human-readable output with a parser expecting a plain numeric field.

6. Use the result in a script

For a health or evidence check, capture the exit status rather than assuming text output means success:

if tapestat -y 5 6 > /tmp/tapestat-report.txt; then
    printf '%s\n' 'tapestat completed'
else
    status=$?
    printf 'tapestat failed with status %s\n' "$status" >&2
    exit "$status"
fi

The temporary path above is only an example; choose a controlled directory for a real service and arrange retention yourself. A successful exit status means the sampling request completed, nothing more: it does not mean a tape was present, that data moved, or that backup performance was good. Check the report text and look for a drive row.

When a parser needs stable units, use -k or -m, disable terminal colouring, and use the ISO time-format variable below if timestamps need an ISO 8601 date:

$ S_COLORS=never S_TIME_FORMAT=ISO tapestat -y -t -k 5 2

These environment variables affect presentation only; they never change tape behaviour. Treat the output as a report, not a machine-readable interface guaranteed across every sysstat release.

7. Diagnose missing or surprising statistics

If the command reports no tape drives, first confirm you are on the host where the drive is actually attached. Then inspect the read-only interfaces the manual mentions:

$ mountpoint /sys
$ find /sys/class/scsi_tape -maxdepth 2 -type f -name stats -print 2>/dev/null
$ ls -ld /sys/class/scsi_tape 2>/dev/null

The exact files sit under /sys/class/scsi_tape/st<num>/stats/. If /sys is not mounted, the command cannot work at all. Mounting filesystems or changing device configuration is an administrative action outside this read-only check, so involve the system owner before reaching for sudo or altering boot configuration.

Do not overreact to small differences between adjacent rows or runs. The kernel statistics come from separate files and cannot be captured as one atomic group, so completions can land between reads. Per-second values are also rounded down, and the actual elapsed interval is tracked per device in milliseconds, so nearby drives can show slightly different rates.

Low wait percentages on a fast LTO drive are not by themselves a fault: a slower drive spends more time waiting, while a fast drive can spend more time receiving filesystem I/O. Look for repeated patterns, stalled throughput and backup duration together rather than treating one percentage as an alarm threshold.

Done means