Following the NVMe spec 1.2.1, we must use id-ctrl to gather some drive info:

(a) In id-ctrl, the field Optional Admin Command Support (oacs - bits 257:256) provides optional capabilities, like the support for Format NVM Command and namespace management, as per the spec:

Bit 3 if set to ‘1’ then the controller supports the Namespace Management and Namespace Attachment commands. If cleared to ‘0’ then the controller does not support the Namespace Management and Namespace Attachment commands.

Bit 2 if set to ‘1’ then the controller supports the Firmware Commit and Firmware Image Download commands.

Bit 1 if set to ‘1’ then the controller supports the Format NVM command. If cleared to ‘0’ then the controller does not support the Format NVM command.

Bit 0 if set to ‘1’ then the controller supports the Security Send and Security Receive commands.


(b) In id-ctrl, the field "Number of Namespaces" (nn - bits 519:516 in struct) shows the number of namespaces set in the adapter currently, important to keep note on this.


(c) In id-ctrl, the field "Format NVM Attributes" (fna - bit 524 in struct) determines the secure erase/format capabilities:
From spec 1.2.1:

Bit 2 indicates whether cryptographic erase is supported as part of the secure erase functionality. If set to ‘1’, then cryptographic erase is supported. If cleared to ‘0’, then cryptographic erase is not supported.

Bit 1 indicates whether cryptographic erase and user data erase functionality apply to all namespaces or is specific to a particular namespace. If set to’1’, then a cryptographic erase of a particular namespace as part of a format results in a cryptographic erase of all namespaces, and a user data erase of a particular namespace as part of a format results in a user data erase of all namespaces. If cleared to ‘0’, then a cryptographic erase or user data erase as part of a format is performed on a per namespace basis.

Bit 0 indicates whether the format operation applies to all namespaces or is specific
to a particular namespace.


(d) In id-ns , the field "Formatted LBA Size" (flbas - bit 26 in struct) determines the LBA data/metadata size the namespace has been formatted with.
From the spec:

Bit 4 if set to ‘1’ indicates that the metadata is transferred at the end of the data LBA, creating an extended data LBA. Bit 4 if cleared to ‘0’ indicates that all of the metadata for a command is transferred as a separate contiguous buffer of data. Bit 4 is not applicable when there is no metadata.

Bits 3:0 indicates one of the 16 supported LBA Formats indicated in this data structure.


(e) In id-ns, there's a "sub-table" with LBA and MS (Metadata Size) information, example:

lbaf  0 : ms:0   lbads:9  rp:0x2 (in use)
lbaf  1 : ms:8   lbads:9  rp:0x2 
lbaf  2 : ms:16  lbads:9  rp:0x2 
lbaf  3 : ms:0   lbads:12 rp:0 
lbaf  4 : ms:8   lbads:12 rp:0 
lbaf  5 : ms:64  lbads:12 rp:0 
lbaf  6 : ms:128 lbads:12 rp:0


So, the algorithm outline would be something like this:

(1) Check id-ctrl for "oacs" - if bit 1 is not set, ABORT.


(2a) Check id-ctrl for oacs bit 3 (namespace management support).
(2b) Check id-ns for "nn".
(2c) Check id-ctrl for "fna" bit 1 ( *per-namespace* secure erasing support ).
-> If "fna" bit 1 is set *and* ("oacs" bit 3 is set *and* "nn" > 1), ABORT
(unsafe, risking to erase all user's namespaces - see [0] below).


(3) Check "fna" bit 2: if set, we're going to use crypto erase, faster and less
degrading to device; if not set, we're going to use regular user erase.

(4) Check id-ns "flbas" to determine the previously used LBA setting.

(5) Execute "nvme format" command with the previously gathered "--ses" option (2 to
crypto erase or 1 to regular user erase), "--lbaf" option (from id-ns flbas) and
with a timeout to be determined (see [1] below).


(6) If any step (1)-(5) fails, fallback to zeroing the nvme device.

[0] Formatting with multiple namespaces is risky - certain drives will erase data in all namespaces. For safety reasons, we could fallback to zeroing the device in case more than 1 namespace is configured, even if fna bit 1 is clear (a buggy device firmware would cause a irreversible data loss in this case). Opinions are welcome!

[1] I think 20/30 minutes as a timeout for nvme formatting is more than enough, I'd like to gather opinions here.