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/18/26 12:21, Warner Losh wrote:
> 
> 
> On Fri, Sep 18, 2026 at 10:27 AM Mark Millard <marklmi@yahoo.com
> <mailto:marklmi@yahoo.com>> wrote:
> 
>     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.
> 
> 
> The nvme standard says < 10 minutes. That's what I implemented
> in the series of commits that you clearly don't have yet :). 
> 
> My advice to you was based on what you'd done. After < 10 minutes,
> it will be good. And the reason for reboot isn't in the DEVICE, but
> rather because the version of FreeBSD doesn't do the resets correctly
> because it timed out and then failed.
>  
> 
>     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.
> 
> 
> It runs to completion. If you reboot too soon, you'll have to format again.
> But once identify returns the new value, it's done.
>  
> 
>     (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.
> 
> 
> Yes. Better to run a newer FreeBSD kernel. It handles this so much better.
>  
> 
>     > 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.
> 
> 
> Yes. Your format finished quickly, but not in the 30s that we have as
> the default timeout today. We then tried to reset the controller, but
> since it was formatting it ignored us. Unless you immediately rebooted,
> things are fine. The next boot will pick it up.
> 
> Warner
> 
>     > . . .

Seems like after synchronizing to main, testing formatting the 1.5T DC
4800 Optane again under the updated FreeBSD OS might be a good idea. I
doubt that it finished the format in 10 minutes, for example.

<https://au.pcpartpicker.com/forums/topic/425127-benchmarking-optane-ssds>

reports:
QUOTE
We ran into some unexpected issues running our benchmark methodology on
the Optane SSDs. Running "nvme format" on an Optane SSD takes
significantly longer (ranging from 7 to 26 minutes on the three drives)
than it does on most NAND-based SSDs (which typically take seconds). But
sometimes our "nvme format" command would hang and never return.

Examining system logs showed the OS detecting a timeout on the drive and
resetting it. There were two causes:

"nvme format" uses a default timeout of 10 minutes, after which the OS
will reset the drive. This is remedied by specifying a larger timeout to
"nvme format" via the "--timeout" argument

Optane SSDs do not like being talked to while performing an "nvme
format". Linux has a daemon named "smartd" that will periodically query
drives for their SMART data. If it does this while an Optane SSD is
performing an "nvme format", the drive will be reset. This is remedied
by stopping "smartd" prior to performing an "nvme format".
END QUOTE

Intel is not as specific in the details but . . .

<https://www.intel.com/content/www/us/en/content-details/841781/technical-advisory-ta-338060-001-nvme-admin-format-command-failure-error-on-intel-optane-ssd-dc-p4800x-series.html>

reports that the involved format times are longer than typical vs.
kernel timeout values. (The document has copying text disabled without a
password.) It also has notes about avoiding issuing admin and I/O
submissions during the format, even explicitly indicating that such is
not supported.

So, once I know, I'll let you know how it went.

(I'm not sure if reformatting for the same 4096 context might be faster
than the original attempts at 512->4096.)

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