Other How to reset/rescan drives after reformatting without reboot?

S

sko

I just had to reformat another SSD to 4k blocksize and once again I was unable to find a way to rescan/reprobe/reset the geom so that e.g. gpart will be able to put anything on it.

I tried camcontrol rescan/reprobe/reset and nvmecontrol reset but gpart always fails with "gpart: Input/output error" when trying to create a partitioning scheme. After a reboot (and the drive being fully re-read) everything works as expected...

Is there any way to force the cam/geom layer to re-read a drive after it has been reformatted with a different sector size?
 
I'm just trying to understand the sequence of steps here:
device say /dev/da0, had filesystem and was currently mounted using say /dev/da0 or /dev/gpt/label?
you unmounted and tried gpart destroy -F /dev/da0

I'm trying to understand where the "reformatted to 4K blocksize" is coming in. I know if you are creating ZFS stuff, you need to make sure the ashift is set correctly before doing zpool create or I think you can set blocksize when formatting a UFS partition.
 
What camcontrol commands did you actually use? Note that camcontrol re...xxx commands all use arguments (see the man page), and those arguments have interestingly complex meaning, with important difference between for example "da0" and "bus:target".
 
mer said:
I'm just trying to understand the sequence of steps here:
device say /dev/da0, had filesystem and was currently mounted using say /dev/da0 or /dev/gpt/label?
you unmounted and tried gpart destroy -F /dev/da0

I'm trying to understand where the "reformatted to 4K blocksize" is coming in. I know if you are creating ZFS stuff, you need to make sure the ashift is set correctly before doing zpool create or I think you can set blocksize when formatting a UFS partition.
Click to expand...
no filesystem involved. those are completely empty disks that e.g. come with 512k sectors and are being reformatted to 4096k sectors (sorry, I just realized I might have mixed up blocks and sectors here :-/) via sg_format or (as of today's M.2 drive) nvmecontrol format -f<num> nvmeN


ralphbsz said:
What camcontrol commands did you actually use? Note that camcontrol re...xxx commands all use arguments (see the man page), and those arguments have interestingly complex meaning, with important difference between for example "da0" and "bus:target".
Click to expand...

I always used the device ID as given by camcontrol devlist e.g. nvme1:

camcontrol reprobe nvme1
camcontrol rescan nvme1
camcontrol reset nvme1



SirDice said:
Try :>/dev/da0 (for disk da0)
Click to expand...

I will give that a try tomorrow.
 
sko said:
I always used the device ID as given by camcontrol devlist e.g. nvme1:
Click to expand...
This might be your problem: nvme1 may no longer be reachable after formatting, so the re... command may be evaporating into the ether. I would suggest sending the command to the bus or bus:target.

Another thing to try: I've never had to reformat an NVME device, but with old-style (spinning rust) disk drives, they may go dead for a while after formatting, or after upgrading the firmware. You may have to wait some time. How long? I don't know for NVME; for disk drives, I would say that if a disk doesn't come back within 5 minutes, it's hopeless, and you need to power cycle things (or throw it in the trash). For disk drives, a formatting operating that has to change all the sectors on the platters (like changing the block size from 512 to 520 or 528 bytes) can take hours, but during that time the drive itself is reachable via the interface, so it should be visible if you ask for "camcontrol devlist", even if at that time it can not create a daX or adaX entry because the partition table is completely unreadable.
 
ralphbsz said:
This might be your problem: nvme1 may no longer be reachable after formatting, so the re... command may be evaporating into the ether. I would suggest sending the command to the bus or bus:target.
Click to expand...

The drive is there and answers with the correct, new sector size when probed via nvmecontrol or smartctl. nvmecontrol identify also shows "Format Progress Indicator: 0% remains". With SAS SSDs and sg_format there is a brief period of time where the drive is busy, then it also answers again to all sg_ commands and also shows the new sector size e.g. with smartctl

It seems gpart (or the cam layer?) still has the old geometry cached somewhere, and when trying to write to the last sector when issueing gpart create -s gpt nda1 of course won't work...
 
And I'm stuck again at this problem...

Installed 4 new NVMe drives into a system, nvmecontrol formatted all their namespaces with 4096 sectorsize, but geom device list still reports 512b sectors:
Code: 
Geom name: nda5
Providers:
1. Name: nda5
   Mediasize: 500107862016 (466G)
   Sectorsize: 512
   Mode: r0w0e0
   descr: WD Red SN700 500GB
   lunid: e8238fa6bf530001001b448b4a4f7ef2
   ident: 231604800581
   rotationrate: 0
   fwsectors: 0
   fwheads: 0

nvmecontrol and smartctl report the correct format:

Code: 
# nvmecontrol identify nvme5ns1
Size:                        122096646 blocks
Capacity:                    122096646 blocks
Utilization:                 122096646 blocks
Thin Provisioning:           Not Supported
Number of LBA Formats:       2
Current LBA Format:          LBA Format #01
Data Protection Caps:        Not Supported
Data Protection Settings:    Not Enabled
Multi-Path I/O Capabilities: Not Supported
Reservation Capabilities:    Not Supported
Format Progress Indicator:   0% remains
Deallocate Logical Block:    Read 00h, Write Zero
Optimal I/O Boundary:        0 blocks
NVM Capacity:                500107862016 bytes
Globally Unique Identifier:  e8238fa6bf530001001b448b4a4f7ef2
IEEE EUI64:                  001b448b4a4f7ef2
LBA Format #00: Data Size:   512  Metadata Size:     0  Performance: Good
LBA Format #01: Data Size:  4096  Metadata Size:     0  Performance: Better

# smartctl -i /dev/nvme5
smartctl 7.3 2022-02-28 r5338 [FreeBSD 12.4-RELEASE-p3 amd64] (local build)
Copyright (C) 2002-22, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Number:                       WD Red SN700 500GB
Serial Number:                      231604800581
Firmware Version:                   111150WD
PCI Vendor/Subsystem ID:            0x15b7
IEEE OUI Identifier:                0x001b44
Total NVM Capacity:                 500,107,862,016 [500 GB]
Unallocated NVM Capacity:           0
Controller ID:                      8215
NVMe Version:                       1.3
Number of Namespaces:               1
Namespace 1 Size/Capacity:          500,107,862,016 [500 GB]
Namespace 1 Formatted LBA Size:     4096
Namespace 1 IEEE EUI-64:            001b44 8b4a4f7ef2
Local Time is:                      Tue Jul 25 21:32:01 2023 CEST

trying to issue :>/dev/nvme5 doesn't do anything; :>/dev/nda5 caused a kernel panic (page fault).
after reboot all 4 namespaces are reported with the correct LBA size - but that's not really what i'd call a 'solution'
 
sko said:
Those were consumer drives, so for all nvmecontrol ns commands I only got the message "controller does not support namespace management".
Click to expand...
OK, sorry, I was thinking about something else (and clearly confusing with illumos' nvmeadm attach/detach where it would detach/attach the target driver to/from namespace).
 
You must log in or register to reply here.
Back
Top