E-Series CHECK CONDITION: Read Sense Data Before Diagnosing a Drive
CHECK CONDITION is a SCSI command status telling the initiator to examine sense information. It is not a complete drive diagnosis. The source’s DE6000 list shows repeated events for Shelf 99, Slot 16 alongside drive-channel and individual-path degradation:
Status, sense and recovery are different layers
GOOD, CHECK CONDITION, BUSY and RESERVATION CONFLICT are familiar SCSI statuses, but the source’s claim that they are the only four possible results is incomplete. CHECK CONDITION can report many conditions, including an unsupported/invalid request; it does not prove that the command was syntactically valid.
Sense data supplies the condition class and detail through its sense key, Additional Sense Code (ASC) and Additional Sense Code Qualifier (ASCQ). Recovery, informational conditions and persistent errors need different responses. A grouped range such as 0x02–0x07 contains distinct conditions, not a single diagnosis:
For example, unit attention can report a state change and data protect can describe an access/protection condition. Neither automatically proves a failed medium. The four-row illustration summarizes selected keys; it is not the complete sense-key registry.
How sense information reaches the initiator
The source contrasts traditional command → CHECK CONDITION → REQUEST SENSE with automatic sense delivery in modern driver/transport stacks. Automatic sense accompanies command completion; it is not returned “inside the CDB,” which is the command descriptor sent to the device. Whether a separate REQUEST SENSE is needed depends on the stack and completion information.
The source’s echo "REQUEST SENSE" | sg_raw /dev/sdX is not a valid sg_raw CDB invocation and is omitted as an executable procedure. Administrators normally start with the array’s complete event/support data and vendor diagnostics. Do not issue an arbitrary raw SCSI request to a guessed device. ATA and NVMe also have their own completion/status mechanisms; that comparison does not replace decoding the actual SCSI record.
A separate MEL event example
This event is Shelf 99, Bay 7, reported by the controller in bay B. It is a separate example from the earlier Slot 16 list. Keep its source time 11/30/24, 5:22:52 PM as given; no timezone is supplied. Sequence 42761 is an ordering identifier. Event type 100A and category Error coexist with priority Informational, attention=false, alert=false and visibility=true in this record.
Do not confuse decimal and hexadecimal ASC values
The raw triplet is 1/18/4. The source calls the middle value decimal 18, equates it to 0x12, then looks up the hexadecimal 18h family. Those interpretations are not interchangeable. Preserve the raw value and verify the format against the array’s full sense information and the applicable vendor decoder.
T10’s numeric ASC registry contains 18h/04h as recovered data using L-EC, with optical-device applicability in that table. Thus the source’s statement that 04 is simply missing from the standard is incorrect. Finding that code does not by itself establish that this HDD record uses the same radix or that an optical-device description is a valid HDD diagnosis. The complete raw bytes remain intact in the original image above.
What can be concluded from these captures
The source interprets the event as a recovered read near LBA 0x00104de, attributes it to media/ECC behavior, suggests background media scanning and concludes there is no impact or data loss. The provided explanation does not demonstrate a verified raw-data decode or prove any of those broader conclusions. A recovery-class status or informational flag alone does not prove a self-repaired healthy drive, no lost data, or no array impact.
Correlate the full sense decode, command, exact drive identity, repeated-event trend, link/path events, array health and recovery actions. Retain and monitor the support data, and use vendor guidance if events recur or health degrades. A CHECK CONDITION entry alone is insufficient grounds either to replace a drive or dismiss it.
Adapted and translated from StorageExpert’s article under CC BY-SA 4.0, with technical corrections and localized illustrations. The author’s original Chinese display-name watermark remains in the two otherwise-English source reference images for attribution.