Re: "nvmecontrol: format request returned error"message for "nvmecontrol format -f 3 nvme1" on a still-new Optane DC P4800X 1.5T : info and questions

On 9/17/26 23:16, Warner Losh wrote:
> Sorry for top posting...
> 
> The problem is that the timeout is taking longer to timeout than our
> default timeout, so
> we're aborting. Since we don't send an abort to the drive by default,
> the command will
> eventually complete. 

But, even if I'd known that, there was no evidence of when it completes
and I've never found documentation for the DC P4800 Optane that reports
on how long to expect it to take. (The Optane's may well be unusually
long?) The device itself had no status light or anything to watch. So
I'd still have had no clue when to cut the power or reboot.

I'm also not aware of anything to check afterwards on the Optane for if
the Optane process was incomplete vs. complete. Only the command
completing successfully was available for status.

(My overall activities ended up showing that incomplete processing still
had the Optane reporting the change to 4096 after the very short time it
had on my first attempt --but it clearly had not finished.)

Note: It was a "1.5T" Optane, so on the long end of the likely
formatting time frames for changing 512 to 4096 (no meta data) for such
a vintage of Optane. Unfortunately, I did not set up to get an automatic
timing of the activity and I was gone when it completed.

> A reboot will see the new format, as weill a
> nvmecontrol reset followed
> by a camcontrol rescan of the b:t that the nda lives at.
> 
> In current, I've fixed this with the following changes.
> 
> commit b4c9e0f5d0e5ad896e6ad211a1a3c1b2fc49011c (HEAD -> main)
> Author: Warner Losh <imp@FreeBSD.org>
> Date:   Sun Sep 13 13:42:51 2026 -0600
> 
>     nvme: Notify namespaces on reset sometimes
> 
>     When we're resetting after a controller failure, and we fix the failure,
>     and we've not resetting as part of initialization, notify the all the
>     children devices of new namespaces. When we failed the controller
>     before, we removed all the namespaces.
> 
>     Sponsored by:           Netflix
> 
> commit 8477839c7ed07078613591fd22e0fc2a231e230e
> Author: Warner Losh <imp@FreeBSD.org>
> Date:   Sun Sep 13 13:41:12 2026 -0600
> 
>     nvme: Refactor namespace notifications for additions
> 
>     When we add a namespace, we have the code inline to do the
>     notifications. Refactor ahead or reuse.
> 
>     Sponsored by:           Netflix
> 
> commit ee66f8ddb69f8d675d993cb9eb783a30b5b4d437
> Author: Warner Losh <imp@FreeBSD.org>
> Date:   Sat Sep 12 13:38:22 2026 -0600
> 
>     nvme: honor Linux passthrough command timeouts
> 
> commit 6a14e1e4d353365516b8c139ccca25a5b480982b
> Author: Warner Losh <imp@FreeBSD.org>
> Date:   Sat Sep 12 13:26:06 2026 -0600
> 
>     nvme: support per-request timeouts
> 
> commit 1cd7985c9beeb1665b9ede23a9c008823c35a96b
> Author: Warner Losh <imp@FreeBSD.org>
> Date:   Sat Sep 12 13:23:26 2026 -0600
> 
>     nvme: add a timeout for Format NVM commands

Cool.

Also, that sequence leads me to notice that I'm overdue to synchronize
to main again.

> 
> I just hit this doing developing some automated drive reformatting software
> because our current settings are so bad we need to reformat!
> 
> Warner
> 
> On Thu, Sep 17, 2026 at 11:56 PM Mark Millard <marklmi@yahoo.com
> <mailto:marklmi@yahoo.com>> wrote:
> 
>     On 7/21/26 11:37, Mark Millard wrote:
>     > Adding Warner to the To list in order to be sure that he sees it.
>     >
>     > So far as I can tell, Warner seems to be likely to be the only one
>     > likely to answer on if there is more that I should do for
>     formatting the
>     > Optane DC P4800X 1.5T based on the below information. So long as he is
>     > aware of the question, there is no reason for him to elevate the
>     > priority for when to potentially answer.
>     >
>     > On 7/17/26 13:19, Mark Millard wrote:
>     >> My attempt to change from (in smartctl output form):
>     >>
>     >> Supported LBA Sizes (NSID 0x1)
>     >> Id Fmt  Data  Metadt  Rel_Perf
>     >>  0 +     512       0         2
>     >> . . .
>     >>
>     >> to:
>     >>
>     >> Supported LBA Sizes (NSID 0x1)
>     >> Id Fmt  Data  Metadt  Rel_Perf
>     >> . . .
>     >>  3 -    4096       0         0
>     >> . . .
>     >>
>     >> reported:
>     >>
>     >> # nvmecontrol format -f 3 nvme1
>     >> nvmecontrol: format request returned error
>     >>
>     >> but afterwards shows:
>     >>
>     >> Supported LBA Sizes (NSID 0x1)
>     >> Id Fmt  Data  Metadt  Rel_Perf
>     >> . . .
>     >>  3 +    4096       0         0
>     >> . . .
>     >>
>     >> It also shows:
>     >>
>     >> Media and Data Integrity Errors:    0
>     >> Error Information Log Entries:      0
>     >>
>     >> Error Information (NVMe Log 0x01, 16 of 64 entries)
>     >> No Errors Logged
>     >>
>     >> dmesg -a shows:
>     >>
>     >> # dmesg -a | tail -7
>     >> nvme1: Resetting controller due to a timeout.
>     >> nvme1: event="start"
>     >> nvme1: event="success"
>     >> nvme1: aborting outstanding admin command
>     >> nvme1: FORMAT_NVM (80) sqid:0 cid:15 nsid:ffffffff cdw10:00000003
>     >> cdw11:00000000
>     >> nvme1: ABORTED_BY_REQUEST (00/07) crd:0 m:0 dnr:1 p:0 sqid:0
>     cid:15 cdw0:0
>     >> nvme1: done aborting outstanding admin
> 
>     I was able to do the low level format via a Dell Ubuntu 22.04 LTS based
>     Precision P5490 laptop --over one of its USB4/Thunderbolt/PCIe ports--
>     using the nmve format command with a command line specified large
>     timeout value. I had to configure the P5490 to not sleep or the like as
>     well. The formatting took considerable time.
> 
>     On FreeBSD, "nvmecontrol format -f 3 nvme1" did not seem to have a
>     variant that could wait for a longer time than the default timeout
>     appeared to be.
> 
>     >>
>     >>
>     >> Is this a problem for use of the media? Did it likely finish what
>     it was
>     >> doing? If it did not finish, what may I do about it?
> 
>     As I understand it now, the FreeBSD error message did indicate that the
>     formatting was messed up (by being incomplete due to timing out).
> 
>     >>
>     >>
>     >> For reference (after the attempt):
>     >>
>     >> === START OF SMART DATA SECTION ===
>     >> SMART overall-health self-assessment test result: PASSED
>     >>
>     >> SMART/Health Information (NVMe Log 0x02, NSID 0xffffffff)
>     >> Critical Warning:                   0x00
>     >> Temperature:                        45 Celsius
>     >> Available Spare:                    100%
>     >> Available Spare Threshold:          0%
>     >> Percentage Used:                    0%
>     >> Data Units Read:                    22 [11.2 MB]
>     >> Data Units Written:                 33 [16.8 MB]
>     >> Host Read Commands:                 862
>     >> Host Write Commands:                210
>     >> Controller Busy Time:               0
>     >> Power Cycles:                       5
>     >> Power On Hours:                     1
>     >> Unsafe Shutdowns:                   1
>     >> Media and Data Integrity Errors:    0
>     >> Error Information Log Entries:      0
>     >>
>     >> and:
>     >>
>     >> # nvmecontrol identify -n 1 nvme1
>     >> Size:                        366284646 blocks
>     >> Capacity:                    366284646 blocks
>     >> Utilization:                 366284646 blocks
>     >> Thin Provisioning:           Not Supported
>     >> Number of LBA Formats:       7
>     >> Current LBA Format:          LBA Format #03
>     >> Metadata Capabilities
>     >>   Extended:                  Supported
>     >>   Separate:                  Not Supported
>     >> Data Protection Caps:        Last Bytes, Type 1
>     >> Data Protection Settings:    Not Enabled
>     >> Multi-Path I/O Capabilities: Not Supported
>     >> Reservation Capabilities:    Not Supported
>     >> Format Progress Indicator:   Not Supported
>     >> Deallocate Logical Block:    Read Not Reported
>     >> Optimal I/O Boundary:        0 blocks
>     >> NVM Capacity:                0 bytes
>     >> Globally Unique Identifier:  00000000000000000000000000000000
>     >> IEEE EUI64:                  5cd2e496b5ea0100
>     >> LBA Format #00: Data Size:   512  Metadata Size:     0 
>     Performance: Good
>     >> LBA Format #01: Data Size:   512  Metadata Size:     8 
>     Performance: Good
>     >> LBA Format #02: Data Size:   512  Metadata Size:    16 
>     Performance: Good
>     >> LBA Format #03: Data Size:  4096  Metadata Size:     0 
>     Performance: Best
>     >> LBA Format #04: Data Size:  4096  Metadata Size:     8 
>     Performance: Best
>     >> LBA Format #05: Data Size:  4096  Metadata Size:    64 
>     Performance: Best
>     >> LBA Format #06: Data Size:  4096  Metadata Size:   128 
>     Performance: Best
>     >>
>     >>
>     >
>     >
> 
> 
>     -- 
>     ===
>     Mark Millard
>     marklmi at yahoo.com <http://yahoo.com>
> 


-- 
===
Mark Millard
marklmi at yahoo.com