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

From: Mark Millard <marklmi_at_yahoo.com>
Date: Fri, 18 Sep 2026 17:50:32 UTC
On 9/18/26 09:27, Mark Millard 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.

Hmm. The mention default timeout. Looking for sysctl's . . .

Would have adjusting the likes of (might not be 0):

dev.nvme.0.timeout_period: 30
dev.nvme.0.admin_timeout_period: 60

have allowed the activity, even on the somewhat older main that I've
been using?

Based on the failing example timeouts I had under ubuntu on the P5490
before I got it working, I'd guess the time was more like 20+ minutes.
So trying 30 minutes for the timeout might have been an alternative had
I noticed those dev.nvme.?.*timeout_period sysctl's.

> 
> 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