NVMe Format and Sanitize: Scope and Completion Checks
Short answer
NVMe Format and Sanitize are different operations. Before choosing either, establish its supported action, the storage it affects and the evidence that will demonstrate completion. A namespace-looking device name does not guarantee a namespace-only erase, and a successful command submission does not by itself prove that a background sanitization has finished.
For Format, distinguish ordinary formatting from the requested Secure Erase Settings. For Sanitize, inspect the supported action and its status log. Accept the result only after reconciling that evidence with the exact device, required scope and approved procedure.
Who this is for
This guide helps authorized operators review directly attached local NVMe storage before an irreversible job. Read-only examples use the nvme-cli v3.1 command layout. That software version is not a claim about the NVMe protocol revision implemented by a drive. Record the installed tool version, model and firmware separately.
The examples cover the traditional subsystem-oriented Sanitize command and its log. Newer namespace-specific sanitization features, specialized command sets, multipath arrangements and NVMe over Fabrics need a procedure that explicitly supports those capabilities. Do not generalize these examples to every NVMe deployment.
Establish identity and topology first
On an authorized Linux workstation with nvme-cli installed, these commands inventory accessible devices and subsystem relationships; they do not initiate formatting or sanitization:
sudo nvme list
sudo nvme list-subsys
Match the reported serial, model and controller path to the physical asset and its namespace inventory. Treat permission failures, missing devices and unexpected multiple paths as unresolved discovery results.
Do not infer the relationship between a controller character device such as /dev/nvme0 and a namespace block device such as /dev/nvme0n1 solely from their numeric suffixes. Similar-looking names are not topology evidence. Recheck identity after reconnecting hardware or changing the storage path.
After identifying the intended controller, the following example retrieves its Identify Controller information:
sudo nvme id ctrl /dev/nvme0
Here /dev/nvme0 is illustrative, not a universal target. Use your reconciled controller. Review optional command support, Format NVM Attributes (FNA) and Sanitize Capabilities (SANICAP) against the device's supported revision and manufacturer procedure. A field's presence is not evidence that every action is supported.
What does Format actually request?
Format can change namespace formatting attributes. Its Secure Erase Settings (SES) determine whether secure erase is requested as part of that operation. The tool's default SES value is zero: no secure erase is requested. Other defined settings request user-data erase or cryptographic erase, subject to device support and scope.
This is why “the format command succeeded” is incomplete evidence. Record the requested setting, not only the command name. Also distinguish the scope of formatting from the scope of a secure erase performed during formatting. The controller's Format attributes can make an operation affect all namespaces even when an operator expected a narrower target.
Do not equate an empty partition table or a selected LBA format with a validated sanitization result. Do not add force, reset or erase options by copying a generic example. This review intentionally supplies no executable destructive command: the approved device-specific procedure must settle those choices first.
What changes when choosing Sanitize?
Sanitize offers distinct actions such as block erase, overwrite and cryptographic erase when supported. They are not interchangeable pass-count settings. Select the action appropriate to the medium and the requirement; the presence of a Sanitize command does not imply support for every action.
For the traditional subsystem-oriented operation covered here, review the whole affected subsystem rather than treating one block-device path as an isolation boundary. Include the effect on other data owners in the authorization decision. A procedure requiring a newer namespace-specific feature must verify that feature explicitly instead of assuming traditional scope rules apply.
Successful command acceptance and successful completion are separate evidence points. A tool may return after starting a background operation unless its selected behavior waits. Continue checking the operation's status through the supported log and manufacturer workflow. Do not substitute a progress percentage for a completion state.
How to read completion evidence
In the v3.1 command layout, this retrieves the Sanitize log. The retain-asynchronous-event option preserves the corresponding event notification rather than acknowledging it through this read:
sudo nvme log sanitize /dev/nvme0 --rae
In v3.1, sanitize-log remains a deprecated alias for older scripts; use log sanitize for new scripts. Similarly, use id ctrl rather than the older id-ctrl spelling. Check your installed help before using either layout; an unknown command is a tool-version issue, not a device sanitization failure.
Preserve the complete status record, including errors and the reported last-operation details. Distinguish never sanitized, in progress, successful completion and failure. The log describes the most recent operation; prove that it corresponds to the current job rather than attaching an old success result to a new request.
Capability-dependent fields also matter. Where purge-request/reporting is supported, success and a report that data was purged are not synonymous. Decode applicable fields using the correct revision and procedure. Do not infer IEEE conformance or certification from an unexplained bit or a generic success label.
When to use this
Use these checks when reviewing an erase runbook, accepting an NVMe job report or deciding whether the selected tool can expose the required scope and completion evidence. Complete the review before requesting any irreversible operation.
When not to use this
Do not use this article as authority to erase an active system drive, affect another tenant's namespace, bypass device restrictions or recover from a failed sanitize operation by experimentation. Retention, backups, ownership and the approved target must already be resolved.
Workflow
- Reconcile the physical asset with controller, subsystem and namespace identities.
- Record tool, driver and device firmware versions; obtain the applicable procedure.
- Review supported actions and affected scope, including Format attributes and other namespaces.
- Approve the exact operation and its prerequisites before execution through that procedure.
- Retain submission results, completion evidence, errors and timestamps with timezone.
- Validate the current job's result against the required disposition. Quarantine unresolved cases.
Verification note: evidence criteria, not a hardware test
No NVMe drive was formatted, sanitized or queried for this article. The commands shown are for the v3.1 layout. A real acceptance record needs device-specific applicability and current-job evidence. A command timeout, unsupported log, changed identity or interrupted operation is an exception requiring investigation, not a reason to mark the asset complete.
Verification checklist
- Identity and namespace relationships are independently reconciled.
- The requested action and scope match the authorization.
- Completion evidence belongs to the current job and includes errors.
- Required capability-dependent status is interpreted, not merely copied.
- An authorized reviewer accepts the result under the applicable policy.
Resale and evidence checklist
Keep the model, serial, firmware, procedure version, actual action, completion evidence and exception decision attached to the same asset. Separate readiness for reuse from confidentiality acceptance.
What not to publish
Retain customer data, sensitive asset identifiers and any key-management evidence in the approved internal system. Public examples should not expose them.
Common mistakes
Avoid assuming Format defaults request secure erase, using numeric device-name similarity as topology proof, treating command return as background completion or declaring a previous successful log to be evidence for today's job.
CliDeck workflow fit
The useful pattern is a repeatable identification, approval and evidence workflow. This article establishes no CliDeck drive support, erase implementation or certification.
FAQ
Is Format always namespace-local?
No. Inspect the relevant Format attributes and secure-erase scope for the actual controller and protocol revision.
Does successful Sanitize status prove every acceptance requirement?
No. It contributes operational evidence. Suitability, scope, required reporting and the final validation decision remain necessary.
Related guides
Read the SSD translation-layer explanation for physical coverage boundaries and the NIST process guide for verification versus validation.