Check a Disk's SCSI to ATA Translation with scsi_satl

An ATA disk behind a SCSI to ATA Translation Layer only helps if the SATL actually translates, and scsi_satl is the quick way to find out. The result is a pass/fail-style count, plus a useful distinction between bad errors and errors the script considers allowable. Allow about ten minutes, assuming you already know the correct device path.

The examples use scsi_satl from sg3-utils 1.46-3ubuntu4, installed here. The local manual page identifies the older sg3_utils 1.36 documentation basis, while the installed script is the authority for what actually runs on this machine. Other releases can shift the underlying utility output or error mapping.

1. Confirm the command and choose the device

Start with read-only checks. You need the sg3-utils package and a SCSI device node for the disk, enclosure or adapter you intend to test:

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

Use a stable path such as /dev/disk/by-id/... when your system provides one. Replace /dev/sgX below with the path for the actual target. Do not guess from a list of disks: a test sends real SCSI commands to whatever you pick.

$ readlink -f /dev/sgX
/dev/sgX
$ test -r /dev/sgX && echo readable
readable

The resolved path and permission result are host-specific. If the device node is not readable, stop and arrange the least privilege needed through your normal device permissions or a controlled sudo invocation. Elevated access may be required for the test, but it does not make an incorrect device safe.

2. Run the normal SAT capability check

Run the command with the device as its final argument:

$ scsi_satl /dev/sgX
sg_inq /dev/sgX
sg_vpd /dev/sgX
sg_vpd -p di /dev/sgX
sg_vpd -p ai /dev/sgX
sg_luns /dev/sgX
sg_turs /dev/sgX
sg_requests -s /dev/sgX
sg_senddiag -t /dev/sgX
sg_modes -a /dev/sgX
sg_sat_identify /dev/sgX

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

The command names above are the checks performed by the installed script. The exact final counts depend on the device. A zero exit status means every mandatory check succeeded according to this script. A non-zero status is the number of bad errors counted, not a generic true-or-false value. Capture the status immediately, before another command overwrites $?.

Some devices need elevated privileges for SCSI pass-through. If the ordinary invocation fails only because of permissions, rerun the same command with sudo, but review the device path again first:

$ sudo scsi_satl /dev/sgX
$ printf 'exit status: %s\n' "$?"

This is a diagnostic operation, not a repair. It does not load a SAT driver, change a disk partition, or configure an enclosure.

3. Read the error counts instead of guessing from one line

By default, the script prints each underlying command name and reports selected SCSI failures beside it. The final total combines errors such as illegal requests, timeouts, syntax failures, file errors, recovered errors and other errors. It separately reports allowable errors for not-ready and unit-attention results.

An allowable error is not proof that the device supports SAT, only that the script did not count that particular result against the bad-error total. Investigate any bad-error count by checking the device path, transport, enclosure firmware and the individual capability implied by the failing command. A drive that is spinning up can also behave differently from one that is fully ready.

For a compact result suitable for a quick check, use quiet mode:

$ scsi_satl --quiet /dev/sgX
total number of bad errors: 0
$ printf 'exit status: %s\n' "$?"
exit status: 0

Quiet mode reduces the progress output; it does not change the checks or the meaning of the exit status. Avoid it for first diagnosis, since the per-command names are what help you spot where a problem begins.

4. Keep command diagnostics in a deliberate log

With --log, stderr from each underlying SCSI utility is appended to scsi_satl.err in the current working directory:

$ mkdir -p /tmp/scsi-satl-check
$ cd /tmp/scsi-satl-check
$ scsi_satl --log /dev/sgX
$ status=$?
$ test -s scsi_satl.err && echo 'diagnostic log has data'
$ printf 'exit status: %s\n' "$status"
exit status: 0

The file is appended to, so a second run can mix messages from both attempts. Use a new directory when you need a clean record. The log can contain device and transport diagnostics, so treat it as operational data and remove it through your normal retention process once it is no longer needed. The script will not clean it up for you.

If the command succeeds and you do not need the diagnostics, leaving the working directory alone is enough to preserve the result without creating a log at all. If you deliberately created a temporary log directory, remove it only after checking nothing else lives inside it.

5. Use verbose mode only when investigating

--verbose passes a verbose request to the underlying SCSI utilities. Their output is normally redirected away by the script, but verbose diagnostics can surface more detail about the device response:

$ scsi_satl --verbose /dev/sgX
$ printf 'exit status: %s\n' "$?"
exit status: 0

Do not treat verbose output as a second test. It only changes how the component utilities report their work; the final bad-error count is still the result to record. If you need the diagnostics as well, combine --verbose and --log in a fresh working directory.

6. Diagnose common failure modes

If the usage message appears, check that a device argument was supplied and that each option is spelt exactly as documented. -h and --help print usage and exit with status 1 in the installed script, so that status is expected for a help request, not a SAT result.

If every check reports a file or unknown error, confirm that the path names the SCSI generic or suitable SCSI block interface exposed by your adapter. A regular file or an arbitrary block path is not a safe stand-in for the intended device. Check access first with ls -l and use the storage topology tools already approved for your host.

If only selected checks fail, preserve the command output and the exit status, then compare the device's enclosure or transport capabilities with the SAT features it claims to provide. scsi_satl checks support; it is not a firmware updater and it will not repair a non-compliant translation layer.