Test Mandatory SCSI Support with scsi_mandat

Run scsi_mandat when a drive looks healthy but you need proof it still answers the basic SCSI commands everything else relies on. It fires INQUIRY, REPORT LUNS, TEST UNIT READY, REQUEST SENSE, VPD and SEND DIAGNOSTIC at the target in sequence and hands back one number you can act on. Allow about fifteen minutes, plus time to identify the correct device. The examples use scsi_mandat from sg3-utils version 1.46-3ubuntu4 on this machine.

This is a read-and-test operation, not a repair tool. It sends SCSI commands to the target, including a diagnostic test. Do not point it at a device that is serving production I/O without checking the storage vendor's guidance and an appropriate maintenance window. You normally need no sudo if your account can open the device, but device permissions may require an administrator to grant access.

1. Confirm the installed utility

Check the binary and package before you go anywhere near real hardware. These commands only read local metadata:

$ command -v scsi_mandat
/usr/bin/scsi_mandat
$ dpkg-query -W -f='${Package} ${Version}\n' sg3-utils
sg3-utils 1.46-3ubuntu4
$ scsi_mandat --help
Usage: scsi_mandat [-h] [-L] [-q] [-v] <device>

The installed script accepts one device argument. Its short options are -h, -L, -q and -v; the long forms are --help, --log, --quiet and --verbose. The manual page is labelled sg3_utils 1.36, but the installed package is newer, so treat the package version and the local command output as the authority.

2. Identify the target without guessing

Use the device path that your storage inventory or SCSI administrator has identified. A SCSI generic node might look like /dev/sg3; a block device might be /dev/sdb. Do not infer the target from the order of /dev/sd* names after a reboot, that order is not a promise.

$ ls -l /dev/sg3
$ test -r /dev/sg3 && echo readable
readable

Replace /dev/sg3 with the real path. If the path is absent, stop and resolve the mapping first. If the test says permission is denied, ask for the minimum access needed to open that device. Adding sudo can make the command run, but it cannot make an incorrect device safe.

Checkpoint: Write down the device identifier, serial or WWN, and the host or enclosure it belongs to before continuing. A wrong target is the most expensive distraction in this whole workflow.

3. Run the normal check

Run the command against the confirmed device:

$ scsi_mandat /dev/sg3
sg_inq /dev/sg3
sg_luns /dev/sg3
sg_turs /dev/sg3
sg_requests /dev/sg3
sg_vpd /dev/sg3
sg_vpd -i /dev/sg3
sg_senddiag -t /dev/sg3

total number of bad errors: 0

The script checks standard INQUIRY, REPORT LUNS, TEST UNIT READY, REQUEST SENSE, VPD information and SEND DIAGNOSTIC. A total of zero means every check returned an accepted result. It does not certify the device, its media, its performance or every command your application happens to use.

There is no success output to infer capacity or health from. If you need those facts, reach for a tool built for them. Keep this check focused on command support and nothing wider.

4. Interpret the exit status

scsi_mandat returns the number of bad errors it counted. That is not how most commands behave, where any non-zero status just means "failed":

$ scsi_mandat /dev/sg3
$ status=$?
$ printf 'scsi_mandat exit status: %s\n' "$status"
scsi_mandat exit status: 0

A status of 0 means all mandatory checks worked as expected. A positive value is a count, so a status of 7 means seven bad results out of the script's seven checks. It is not a SCSI sense code, and you should not translate it into a generic "device failed" message without reading the actual output.

For monitoring, preserve the count and the command output together. A simple shell wrapper can tell success apart from a result that needs investigation:

if scsi_mandat /dev/sg3; then
    printf '%s\n' 'mandatory SCSI checks passed'
else
    status=$?
    printf 'mandatory SCSI checks returned %s\n' "$status" >&2
    exit "$status"
fi

5. Reduce output or record command errors

Use --quiet when the human-readable list is just noise and you only want the final count:

$ scsi_mandat --quiet /dev/sg3
total number of bad errors: 0

Use --verbose when the underlying sg_* utilities need to show their SCSI or operating-system diagnostics:

$ scsi_mandat --verbose /dev/sg3
sg_inq -v /dev/sg3
... diagnostic output from the installed sg3-utils tools ...

The literal ellipsis above is explanatory, not output to paste. Exact diagnostics depend on the device and kernel. The local script also accepts repeated verbosity such as -vv and -vvv, though the manual only documents the single -v option. Treat verbose output as device-specific evidence, not a stable machine-readable format.

To append stderr from the SCSI commands to scsi_mandat.err in the current directory, use --log:

$ mkdir -p /tmp/scsi-mandat-investigation
$ cd /tmp/scsi-mandat-investigation
$ scsi_mandat --log /dev/sg3
$ sed -n '1,120p' scsi_mandat.err

The log file is created or extended in whichever directory you launch the command from. It is not automatically rotated or removed. Keep it with the run record, and remove it later only if your retention policy allows deletion. The test itself does not touch the target's files.

6. Diagnose a failed or unsuitable test

First rerun without --quiet so each failing check is visible. Then compare the target path, permissions and transport with the inventory. An operating-system pass-through failure often says more about the node or access path than about SCSI command support.

For a harmless local smoke test, /dev/null shows what an unsuitable target looks like, though it is not a SCSI device and cannot pass:

$ scsi_mandat --quiet /dev/null
  unknown exit status for sg_inq: 75
  unknown exit status for sg_inq: 75
  unknown exit status for sg_inq: 75
  unknown exit status for sg_inq: 75
  unknown exit status for sg_inq: 75
  unknown exit status for sg_inq: 75
  unknown exit status for sg_inq: 75

total number of bad errors: 7
$ printf 'status: %s\n' "$?"
status: 7

The repeated wording is a quirk of this installed script: several different helper commands get reported under the same text, sg_inq. Do not use that text alone to decide which check actually failed. The command names printed by a non-quiet run, and any saved verbose diagnostics, give better context.

Done means