SCSI and SAS Sanitization: Target, Support and Completion

Short answer

For SCSI/SAS sanitization, first prove which logical unit a command reaches, then establish support for the selected sanitize action, and finally collect its terminal result. A physical SAS connector, a successful INQUIRY or an accepted request does not establish all three facts.

Keep an array-exported virtual disk separate from an individually identified physical drive. Qualify the controller and enclosure path before an irreversible operation. If the path, device identity or supported action remains uncertain, stop at discovery and resolve the uncertainty through the storage platform's supported procedure.

Who this is for

This guide is for authorized storage administrators and ITAD operators preparing enterprise disks for reassignment or release. It covers discovery and evidence decisions on a Linux SCSI pass-through path. It is not an erase command for a production array, an unknown USB bridge or an unidentified /dev/sgN node.

Command forms were reviewed against pinned upstream sg3_utils documentation on October 28, 2026. The INQUIRY and operation-code manuals identify the 1.49 series; the REQUEST SENSE manual retains a 1.48 header and the sanitize manual a 1.46 header. These are documentation scopes, not a claim that an installed binary or device was tested. Check the local version and help before using the examples.

When to use this

Use the workflow before approving a sanitize procedure, when moving a disk between enclosures, or when a previous request returned an ambiguous result. A change from an HBA path to a RAID-controller path can change the target being addressed even if the capacity appears familiar.

Build one evidence row per intended physical drive or explicitly scoped logical unit. Decide which of those you are releasing. A whole enclosure, an exported volume and a bare drive are different disposal objects and need different coverage records.

When not to use this

Do not start while the disk remains an active array member, a mounted filesystem, a multipath resource used by another host, or part of a retention hold. Resolve ownership, application shutdown and required recovery copies through the responsible storage administrator.

Do not clear reservations, change controller mode or detach members merely to make a command work. Those changes can affect other data and require their own platform procedure. A rejected discovery command is an evidence gap, not permission to try increasingly intrusive operations.

Workflow

1. Bind the operating-system node to the asset

Obtain the enclosure/slot mapping and physical label through the supported inventory workflow. Compare the drive's stable identifiers with the intended asset record. A transient device number can change after reboot, rescanning or cable movement; it must not be the sole release identifier.

The following local queries do not select a target or send an erase request:

sg_inq --version
sg_opcodes --version
sg_requests --version
sg_sanitize --help

After mapping the actual node and obtaining authorization for discovery, these examples request identification and supported-operation information. /dev/sgN is a placeholder, not an instruction to enumerate and operate on every generic node:

sg_inq /dev/sgN
sg_inq --id /dev/sgN
sg_opcodes /dev/sgN

sg_inq --id decodes Device Identification VPD page 0x83. Retain the identifier's association and context: an identifier for a port is not automatically the identifier for the logical unit. Reconcile the returned information with the enclosure inventory and physical label before proceeding.

Do not use a shell wildcard or bulk loop for this discovery-to-erase transition. Review a single mapped target first. If a tool prints a controller or virtual-disk identity where a physical drive was expected, resolve the discrepancy instead of treating the name as cosmetic.

2. Distinguish opcode support from action support

The default sg_opcodes query reports supported operation codes and can distinguish service actions. Save the relevant SANITIZE entries, including their action information. An opcode-only summary is insufficient if the intended action has not been established. An unsupported REPORT SUPPORTED OPERATION CODES request also does not prove every sanitize action is absent; it may reflect the target or path. Record that ambiguity.

Use the exact model, firmware and product variant to corroborate reported capabilities. A concrete dated example is the Seagate Exos 7E8 SAS Product Manual 100827318 Rev. A. Its supported-command table lists overwrite sanitization and limits cryptographic erase to SED drives. Do not convert that family example into a promise for every SAS drive, or assume a non-SED variant implements a cryptographic operation.

Store the manual revision and the installed firmware alongside the capability response. A product-family marketing name is too coarse to select an irreversible action.

3. Establish what the path exposes

Ask whether the operating system reaches the physical drive, a controller-created logical unit or a translated interface. Document the host adapter, controller firmware, enclosure and any multipath relationship that affects this mapping. A working read path does not itself qualify sanitize pass-through.

For a virtual disk, use the array vendor's supported sanitization workflow and its definition of scope. Do not assume a command against the virtual disk sanitizes every member, spare, removed disk, persistent cache or snapshot. If the intended result is bare-drive release, obtain individually attributable treatment evidence for each physical asset through a supported path.

Consult the companion RAID and snapshot scope guide before treating a volume-level result as an enclosure-level result.

4. Approve an operation-specific runbook

Choose the action only after its capability, target and confidentiality scope are established. Define preconditions, expected completion mechanism, power-loss handling, failure state and acceptance criteria before execution. Include the exact supported drive/tool/controller combination in the approved runbook.

The sg3_utils sanitize interface distinguishes block erase, overwrite and cryptographic actions. Its --early option can return after starting an immediate operation; default monitoring and --wait have different completion behavior. These are tool semantics, not hardware support checks. This guide intentionally supplies no destructive invocation for an unidentified model and path.

A dry run is also not an erase or qualification result. Do not mark the asset sanitized because a parser accepted options. Equally, an elapsed-time estimate cannot replace a final device result.

5. Preserve progress and terminal evidence

For an operation already started through an approved procedure, use its documented monitoring path. A single REQUEST SENSE progress query can be expressed as:

sg_requests --progress /dev/sgN

This is a status request, not a command to start sanitization. Coordinate diagnostic access with the storage owner rather than issuing competing polling loops from several hosts. Preserve errors and full response context in restricted evidence; a progress percentage alone is not a release decision.

After communication loss, mark the record unresolved until identity and operation state are reconciled. Do not power-cycle a device as a generic cancellation strategy. Check model-specific continuation and failure semantics, then use the supported recovery procedure. A device refusing reads during treatment does not establish successful completion.

6. Review the result before physical release

Keep the initiation record, monitoring record and final status attached to the same stable asset identity. Assess anomalies, inaccessible areas, method suitability and any excluded copies. If the terminal result or intended scope cannot be supported, segregate the drive for additional treatment or an authorized alternative disposition.

NIST SP 800-88 Rev. 2, September 2025, separates checking sanitization outcomes from accepting those outcomes as effective. Use that distinction: request acceptance, process completion and confidentiality acceptance are separate fields in the job record.

Verification checklist

• Does the OS target resolve to the authorized physical asset or explicitly identified logical unit?
• Do reported capabilities and exact model documentation support the selected action?
• Is the controller/enclosure path qualified for that action and scope?
• Are initiation, monitoring, terminal result and interruptions attributable to one target?
• Are excluded storage components and other data copies documented?
• Has a reviewer accepted the result for the intended destination?

Verification note: discovery criteria, not a drive test

No INQUIRY, sanitize, REQUEST SENSE or other hardware command was executed for this article. The command forms were checked against upstream manuals; the model-specific support distinction was checked in a product manual. An actual run needs installed versions, device responses, a qualified path and accepted completion evidence. Neither these examples nor command success establish certification.

Resale and evidence checklist

Retain model, stable asset identity, firmware, treatment method, supported path, terminal result, exceptions and reviewer approval. Reconcile every released drive with the physical shipment. A fictional manifest of eight drives with seven accepted results still has one outstanding asset; do not close it as an eight-drive success.

What not to publish

Keep customer identifiers, WWNs, serials, controller topology, raw diagnostic payloads and any recovered content in restricted evidence. Public summaries should describe the method and honest scope without exposing the storage environment.

Common mistakes

Avoid choosing an action from interface branding, reusing a device node after a topology change, interpreting early return as completion, and applying virtual-disk evidence to all physical members. Do not select cryptographic erase merely because it is fast; its prerequisites and key-copy boundaries require separate assessment.

CliDeck workflow fit

A repeatable checklist and transcript can keep discovery, operator decisions and terminal evidence together. Attach the authoritative storage-tool result to the asset record rather than relying on a console screenshot alone. This workflow description does not claim that CliDeck currently implements SAS erasure or certifies a storage controller.

FAQ

Does a SAS connection imply SANITIZE support?

No. Establish support for the selected action on the exact device and qualified path.

Is a failed opcode query proof that sanitization is impossible?

No. It leaves an unresolved capability or path question. Use the supported platform documentation and record the limitation.

Can I use FORMAT UNIT as a synonym for SANITIZE?

Do not substitute operations based on similar user-interface wording. Qualify the exact command's purpose, coverage and completion behavior for the device.

Related guides

See SATA erase state and evidence, NVMe scope and completion checks, and cryptographic erase prerequisites.