Read SAF-TE Enclosure Status Safely with sg_safte

An old RAID chassis starts flashing a fault light with no clear cause, and sg_safte reads its SAF-TE status without touching a single drive. It covers the default configuration report, per-slot status, usage counters, global flags and safe capture of the underlying response. Allow about fifteen minutes if you already know the correct SCSI generic device.

• What it will not do: insert, remove or reconfigure a drive. Every command here is a read.
• What you need: the sg3-utils package and access to a SAF-TE device, normally a path such as /dev/sg1. A device path is not interchangeable with a disk partition, so check it before querying anything.
• Versions used here: package sg3-utils 1.46-3ubuntu4, binary reporting Version string: 0.33 20180628, manpage labelled sg3_utils-1.43 and dated April 2016. Do not assume every release formats its text identically.

1. Find and identify the SAF-TE device

sg_safte expects a SAF-TE device. The manual describes either a storage array controller with SCSI peripheral device type 0xc or a generic processor device with type 0x3. If you have several generic devices, identify them with sg_inq before choosing one:

$ sg_inq /dev/sg1

Use the path that your host administrator or storage documentation identifies as the enclosure interface. Do not guess based only on the number in /dev/sg1, because device numbering can change after a reboot or hardware change.

$ test -c /dev/sg1 && printf '%s\n' 'SCSI generic device exists'
SCSI generic device exists

Most status reads are ordinary, non-modifying queries, but they still need permission to open the device. If the command reports a permission error, use the least privilege your system permits: a group membership or a narrowly scoped sudo invocation, not root by habit.

2. Read the enclosure configuration

With no option, sg_safte performs the same operation as --config. It sends a SCSI READ BUFFER command with buffer ID 0 and reports the enclosure hardware resources:

$ sg_safte --config /dev/sg1

The exact lines depend on the enclosure and its SAF-TE implementation, so treat the output as device data, not a fixed schema. A successful command exits with status 0; capture that status immediately if a script needs to tell a good read from a transport or device error:

$ sg_safte --config /dev/sg1
$ status=$?
$ printf 'sg_safte exit status: %s\n' "$status"
sg_safte exit status: 0

3. Inspect slot status and insertion history

• Current slot state: --devstatus issues Read Device Slot Status, READ BUFFER ID 4. This is the report you want for the current state of each drive or slot.

$ sg_safte --devstatus /dev/sg1

• Insertion history: --insertions issues Read Device Insertions, READ BUFFER ID 3, reporting how many times devices have been inserted while the RAID system was powered on.

$ sg_safte --insertions /dev/sg1

These are observations, not repair commands. A slot report is not proof that a disk can be removed safely. Confirm the enclosure's supported replacement procedure, redundancy state and host multipath arrangements before any physical intervention.

4. Read usage counters and enclosure state

For the RAID device's total usage time and power-on cycle count, use --usage, which reads buffer ID 2:

$ sg_safte --usage /dev/sg1

For the operational state of enclosure components, use --encstatus, which reads buffer ID 1:

$ sg_safte --encstatus /dev/sg1

The --flags option reads buffer ID 5 and reports the most recent global flags from the RAID processor:

$ sg_safte --flags /dev/sg1

Run one report at a time when troubleshooting. Keeping each command and its output separate makes it easier to line up a component state, a slot event and a global flag against the same observation time.

5. Capture a response for further analysis

Use --hex when a human-readable hexadecimal dump of a READ BUFFER response is more useful than the decoded report. Used once, it prints the first READ BUFFER response, which is normally the configuration. Repeating the option prints subsequent READ BUFFER responses as well:

$ sg_safte --hex /dev/sg1 > safte-response.txt
$ test -s safte-response.txt && printf '%s\n' 'hex response captured'
hex response captured

Use --raw for binary output instead. Redirect it to a new file, not a terminal, and do not mistake a successful write for a decoded report:

$ sg_safte --raw /dev/sg1 > safte-response.bin
$ file safte-response.bin

Shell redirection truncates an existing destination before sg_safte starts. If the capture matters, choose a new filename or preserve the old one first:

$ test ! -e safte-response.bin || cp --preserve=all safte-response.bin safte-response.bin.bak
$ sg_safte --raw /dev/sg1 > safte-response.bin.new
$ status=$?
$ if [ "$status" -eq 0 ]; then mv safte-response.bin.new safte-response.bin; else rm -f safte-response.bin.new; fi
$ exit "$status"

6. Separate reporting errors from device problems

Add --verbose when you need more diagnostic output:

$ sg_safte --verbose --devstatus /dev/sg1

Use --help and --version to confirm the local interface without querying enclosure state:

$ sg_safte --version
Version string: 0.33 20180628

If a command fails, first check the path and permissions, then confirm the target really is a SAF-TE-capable device. A generic SCSI enclosure services device is a different interface: the manpage points to sg_ses for SPC-4 SES devices with peripheral type 0xd. Do not swap tools merely because both devices sit in the same storage enclosure.

SAF-TE itself is based on an old 1997 intermediate review document, and that age shows: vendor-specific fields and formatting vary. Preserve the raw or hexadecimal response when reporting an incident, and include the package version and command line used.