Check SCSI Device Readiness and Timing with sg_turs

You will send a SCSI TEST UNIT READY command to a device, distinguish a ready result from a documented not-ready result, and optionally measure the command overhead. The examples use sg_turs from Ubuntu package sg3-utils 1.46-3ubuntu4. The installed binary reports version 3.48 20210102.

Allow about ten minutes. You need a Linux shell, sg3-utils, and the path to a SCSI generic device such as /dev/sg0. A real TEST UNIT READY command can wake a disk or cause a device to answer a status request. It does not write user data, but do not aim it at an unknown device during a production incident without checking the target first.

1. Check the installed command

Start with read-only checks. These do not contact a storage device and do not need elevated privileges:

$ command -v sg_turs
/usr/bin/sg_turs
$ dpkg-query -W -f='${Package} ${Version}\n' sg3-utils
sg3-utils 1.46-3ubuntu4
$ sg_turs --version
Version string: 3.48 20210102

The local help confirms the option spelling accepted by this build:

$ sg_turs --help
Usage: sg_turs [--delay=MS] [--help] [--low] [--number=NUM] [--num=NUM]
               [--progress] [--time] [--verbose] [--version] DEVICE
...

Checkpoint: if command -v finds a different binary, stop and inspect that installation before comparing results with this guide.

2. Identify the target without changing it

Use a device path supplied by your storage inventory or by a SCSI mapping tool. Do not guess from a familiar disk name. For a generic device, record the exact path in a shell variable:

$ DEVICE='/dev/sg0'
$ test -e "$DEVICE" && printf 'target exists: %s\n' "$DEVICE"
target exists: /dev/sg0

The command opens its device read-only, but the kernel still sends a SCSI command to the target. If you only need to verify the syntax, stop after the previous checkpoint. Do not use /dev/null as a substitute for a SCSI device: it cannot answer TEST UNIT READY.

Access to /dev/sg* is commonly restricted by device permissions. If the command later reports an access error, inspect ls -l "$DEVICE" and your group membership. Use sudo only when your operating procedure permits it and you have confirmed the path; privilege does not make an incorrect target safe.

3. Send one readiness check

Run the default operation against the confirmed target:

$ sg_turs "$DEVICE"
$ status=$?
$ printf 'exit status: %s\n' "$status"
exit status: 0

With no count option, sg_turs sends one TEST UNIT READY command. A status of 0 means the utility completed successfully; for a mechanical disk, the manual describes this as the device being spun up and ready to accept commands. The command has no associated data: it is a six-byte SCSI command and receives a SCSI status response.

The useful failure case is exit status 2, which represents the SCSI NOT READY sense key. Report that as a device readiness result, not automatically as a broken disk. A device can be starting, unavailable, or busy with a long operation. Other exit values have wider meanings documented by sg3_utils(8), so retain the actual status and diagnostics.

Checkpoint: capture $? immediately, as in the example. Running another command first replaces the status you need to diagnose.

4. Repeat the check with an explicit count

Use --num or its equivalent --number when you need repeated commands:

$ sg_turs --num=5 "$DEVICE"
$ printf 'exit status: %s\n' "$?"
exit status: 0

The default count is 1. The count accepts numeric suffixes, including k for 1,024 and MB for 1,000,000, plus hexadecimal forms beginning with 0x or ending in h. Keep a diagnostic test small. A large count can hold a device open and produce a long stream of requests, even though the command is read-only.

Add a delay before every command with --delay=MS:

$ sg_turs --num=5 --delay=1000 "$DEVICE"
$ printf 'exit status: %s\n' "$?"
exit status: 0

The delay is in milliseconds and applies before each TEST UNIT READY command. It is not a timeout for a command that is already in progress. If a device is slow or not ready, use the device and kernel diagnostics to understand that state rather than assuming this delay will make it ready.

5. Measure command overhead

Combine a count with --time when you want the total duration and average commands per second:

$ sg_turs --num=100 --time "$DEVICE"
$ printf 'exit status: %s\n' "$?"
exit status: 0

The exact timing line depends on the installed build and the device. Use it to compare two controlled runs, not as a benchmark of the disk's throughput. TEST UNIT READY transfers no payload, so the result mostly reflects command, pass-through and device response overhead. Keep the target, count, delay and system conditions recorded alongside the measurement.

The --low option selects a lower-level pass-through interface when progress reporting is not in use. It is intended to save a little time per command. Do not treat it as a different readiness test, and do not combine timing results from different modes without recording the mode used.

6. Handle progress reporting carefully

--progress asks for a percentage when progress information is available in sense data:

$ sg_turs --progress --num=3 "$DEVICE"
$ printf 'exit status: %s\n' "$?"
exit status: 0

This option is for polling progress from an earlier long-running SCSI operation, not for ordinary health monitoring. When a progress indication is detected and the count is greater than 1, the utility waits 30 seconds before later checks. Supplying --delay=MS changes that wait to the requested delay. Progress mode ignores --time.

Modern SCSI guidance prefers REQUEST SENSE for polling progress, and the sg3-utils manual points to sg_requests for that role. If you are monitoring a format, tape operation or another long command, check the operation's procedure before choosing a polling command.

7. Keep the test reversible

These examples do not alter files, partition tables, media or persistent configuration, so there is no undo command. Stop a repeated run with Ctrl-C if it is taking longer than expected. If the target was waking or becoming busy, allow the device to settle and confirm its state with the storage system's normal tools before retrying.

Do not add --verbose to a script just to make a successful check look reassuring. Use it while investigating a failure, capture the diagnostic output, and remove it again when the script's output is consumed by monitoring. For shell automation, branch on the exit status and preserve non-zero values instead of converting every failure into "not ready".