PM9A3 Firmware / ERRORMOD related to fw version

[vanfront]

Guys, I have a bunch of PM9A3 U.2 3.84TB drives (sourced from eBay, a chinese seller…), P/N MZQL23T8HCLS-00B7C (the 00B7C seem to be for China or what). I was able to upgrade the firmware to GDC56C2Q using the Samsung DC Toolkit ver. 2.1 (I'm running Windows Server 2022). I cleaned all the drives using diskpart and Reset-PhysicalDisk (the seller didn't clean the partitions.…, at least they were empty). So far so good. But I spotted two issues:

Issue 1: The DC Toolit lists bogus drive sizes; originally, three of the drives were listed with the correct 3.84 TB size, and two with the same bogus value — drives had different firmware versions, GDC51C2Q vs GDA53C2Q

What can go wrong here? Shall this be of a concert, or is it just a bug in DC Toolking? Windows sees the drives with the correct size, can format them etc. Note that other DC Toolkit versions won't see these drives.

Issue 2: one of the drives has a 4096 B logical sector size, others have 512 B — also, these drives are the first ever I've seen to claim a 256 kB (!) physical sector size

How do I change the logical sector size, either all to 4096 or to 512 B? And which one would you recommend? I can't figure this out using the DC Toolkit. The utility won't let me format the drives, stating the driver does not support it. I haven't found a Samsung driver suitable for WS2022, so running on the windows inbox driver.

 

[vanfront]

Guys, I have a bunch of PM9A3 U.2 3.84TB drives (sourced from eBay, a chinese seller…), P/N MZQL23T8HCLS-00B7C (the 00B7C seem to be for China or what). I was able to upgrade the firmware to GDC56C2Q using the Samsung DC Toolkit ver. 2.1 (I'm running Windows Server 2022). I cleaned all the drives using diskpart and Reset-PhysicalDisk (the seller didn't clean the partitions.…, at least they were empty). So far so good. But I spotted two issues:

Issue 1: The DC Toolit lists bogus drive sizes; originally, three of the drives were listed with the correct 3.84 TB size, and two with the same bogus value — drives had different firmware versions, GDC51C2Q vs GDA53C2Q

What can go wrong here? Shall this be of a concert, or is it just a bug in DC Toolking? Windows sees the drives with the correct size, can format them etc. Note that other DC Toolkit versions won't see these drives.

Issue 2: one of the drives has a 4096 B logical sector size, others have 512 B — also, these drives are the first ever I've seen to claim a 256 kB (!) physical sector size

How do I change the logical sector size, either all to 4096 or to 512 B? And which one would you recommend? I can't figure this out using the DC Toolkit. The utility won't let me format the drives, stating the driver does not support it. I haven't found a Samsung driver suitable for WS2022, so running on the windows inbox driver.

OK, so I was able to resolve it:

Ad Issue 1: I further upgraded to GDC5B02Q. Kudos to @111alan, apparently your drive is the same p/n as mine so I tried the "B0" version and it worked. Now the drives can be seen by DC Toolkit versions 2.1 and 3.0, and the latter displays the correct size.

Ad Issue 2: Ubuntu and nvme-cli for the rescue… I formatted and santized all the drives to 4 kB sectors. At least I learned how to do discrete device assignment of PCI device to a VM under Hyper-V

So the only strange thing are the 256 kB physical sectors.

 

[dante4]

So the only strange thing are the 256 kB physical sectors.

That's quite literally what their physical sectors are. Not a single SSD use 4k inside chips. But because of combability problems - you see 512b and 4k

https://www.csa.iisc.ac.in/~vg/teaching/E0-253/slides/SSD-FS.pdf

 

[vanfront]

That's quite literally what their physical sectors are. Not a single SSD use 4k inside chips. But because of combability problems - you see 512b and 4k

https://www.csa.iisc.ac.in/~vg/teaching/E0-253/slides/SSD-FS.pdf

Yeah, that's fine. However, it's the first SSD where I've seen this exposed as the physical sector size. I checked a dozen of different SSDs I have here around and none of them behaves like that.

 

[joerambo]

I am not expert in this matter, but 256KB indirection unit would be huge. Aren't they TLC?
For example P5316 is QLC drive and has 64KB indirection unit and that is already considered big (large? sorry not native english speaker here) for "enterprise" drive. The next generation P5336 moved to 16KB indirection unit.

Would a sane vendor allow 64x write amplification in some heavy random 4K write workload? I dont' know, but it does not make much sense to me.

Where is this 256KB physical sector being reported?

 

[dante4]

I am not expert in this matter, but 256KB indirection unit would be huge. Aren't they TLC?
For example P5316 is QLC drive and has 64KB indirection unit and that is already considered big (large? sorry not native english speaker here) for "enterprise" drive. The next generation P5336 moved to 16KB indirection unit.

Would a sane vendor allow 64x write amplification in some heavy random 4K write workload? I dont' know, but it does not make much sense to me.

Where is this 256KB physical sector being reported?

FYI, 256KB is what Blocks (erase blocks) is actual size in almost ANY ssd. Just some reports different information. The smallest size I know is 128KB. Currently you are mixing indirection unit and physical block size, they are not same. Indirection unit is LBA, it's Logical unit, not physical one

 

[joerambo]

FYI, 256KB is what Blocks (erase blocks) is actual size in almost ANY ssd. Just some reports different information. The smallest size I know is 128KB. Currently you are mixing indirection unit and physical block size, they are not same. Indirection unit is LBA, it's Logical unit, not physical one

Thanks for clarifying this, I was too focused on indirections units.

Still, it is completely not clear, why would device report its Erase Block size as physical sector size?

Again, not expert here, but Erase block size should only come into play when running out of ready flash blocks to write to?
While Indirection unit size would come into play for each read/write? Same analogy with 512e / 4kn drives. Read 512 bytes at some LBA, 4KB will get read from media. Write 512 byte at some LBA -> drive will need to do a read/modify/write 4KB.

I assume same happens with those 16/64kb drives, even when formatted with 4K, each read/write will touch whole IU sized chunk on drive. And then obviously FTL will do its magic to place said LBA in some "erase block sized" chunk of flash.

Again, makes more sense to me to report IU, esp if it's larger than 4KB so software like mdadm, lvm etc can make optimal decisions about chunk sizes in RAID etc.

 

[dante4]

Thanks for clarifying this, I was too focused on indirections units.

Still, it is completely not clear, why would device report its Erase Block size as physical sector size?

Again, not expert here, but Erase block size should only come into play when running out of ready flash blocks to write to?
While Indirection unit size would come into play for each read/write? Same analogy with 512e / 4kn drives. Read 512 bytes at some LBA, 4KB will get read from media. Write 512 byte at some LBA -> drive will need to do a read/modify/write 4KB.

I assume same happens with those 16/64kb drives, even when formatted with 4K, each read/write will touch whole IU sized chunk on drive. And then obviously FTL will do its magic to place said LBA in some "erase block sized" chunk of flash.

Again, makes more sense to me to report IU, esp if it's larger than 4KB so software like mdadm, lvm etc can make optimal decisions about chunk sizes in RAID etc.

As for why it's reported like this - I have no idea. Physical sector size literally means nothing outside of information for end user.
Also, you are slightly incorrect, SSD needs to modify a lot more than just 4k. 4k is just "page". There two types of entity, pages and blocks. Block is like a book, it's consist of multiple pages (from 128 to 512)

It's slightly hard to explain it simple, since I'm not SSD engineer, but:
Page is 4k (or 512b, yes you can make page 512b, then block will be 512b*512 pages), you can read page, you can write page. But you can't erase page. Why erase is important? Because you can't overwrite data, you can only overwrite zeroes.

So what happens when you change data? You read old page, you change data (in memory), you write page to new location in the same block (or even new block).

But you don't delete old page, because to erase page you need to erase whole block. So how you do it? You copy whole block (minus old pages, which also includes garbage from deleted files) and a new modified pages to new empty block. And then erase the old block.

Maybe Samsung throught that it's better to give information about it, also if you format Samsung drive to 512b/4k it will give you different size of Block (since block is collection of pages).


You can also read this for better understanding, it's explain in details how FTL works (and why you can lose information when power goes off)

Coding for SSDs – Part 3: Pages, Blocks, and the Flash Translation Layer | Code Capsule

This is Part 3 over 6 of "Coding for SSDs", covering Sections 3 and 4. For other parts and sections, you can refer to the Table to Contents. This is a series of articles that I wrote to share what I learned while documenting myself on SSDs, and on how to make code perform well

codecapsule.com

 

[DouglasteR]

Can i ask for some help ?

After a powerloss my faithfull 2TB PM863 SATA "died" and after some fussing i got the dread ERRORMOD:


After reading all the threads, i tried the following:

https://i.postimg.cc/k4Yd8Q65/tes.png

While it says that the update was a sucess, the drive still is in the same state ?

Do anyone have any idea ?

Thanks.

 

[DarkServant]

Can i ask for some help ?

After a powerloss my faithfull 2TB PM863 SATA "died" and after some fussing i got the dread ERRORMOD:

While it says that the update was a sucess, the drive still is in the same state ?

Do anyone have any idea ?

Thanks.

The Firmware is an pm863 one and not for an pm863a? And did you have secure-erased the drive after the flashing and power down/up cycle?

 

[DouglasteR]

The Firmware is an pm863 one and not for an pm863a? And did you have secure-erased the drive after the flashing and power down/up cycle?

I believe it's a PM863, here's the label on it:


I've tried to secure erase it but it fails.

Thanks

 

[DarkServant]

I believe it's a PM863, here's the label on it:

I've tried to secure erase it but it fails.

Thanks

I can only point to Samsung SSD resurrection – [mjuː]wave anyway. I never encountered this problem myself and i hope it stays this way.

 

[tssrshot]

OK, so I was able to resolve it:

Ad Issue 1: I further upgraded to GDC5B02Q. Kudos to @111alan, apparently your drive is the same p/n as mine so I tried the "B0" version and it worked. Now the drives can be seen by DC Toolkit versions 2.1 and 3.0, and the latter displays the correct size.

Ad Issue 2: Ubuntu and nvme-cli for the rescue… I formatted and santized all the drives to 4 kB sectors. At least I learned how to do discrete device assignment of PCI device to a VM under Hyper-V

So the only strange thing are the 256 kB physical sectors.

Your scenario is exactly what I’m going through right now on a bunch of high end SQL Servers. Problem is, in Win2022 and SQL 2022, it refuses to allow Ag installations to these drives because it will not allow 256 Physical Sector Block devices. I’ve never seen anything like this.

My drives are: SAMSUNG MZ1L23T8HBLA-00A07. But I’ve not done Firmware route yet. Anyone got any ideas? Sitting on 90+ TB of NVME, but can’t proceed.

 

[DaveP]

Hopefully someone here can help me out. I've bought several of what I thought were Samsung PM9A3 3.84TB M.2 from eBay, but they are part number MZ1L23T8HBLA-00AMV . They seem to work fine with full capacity available, but are only reporting support for 1 namespace, not 32 as I was expecting. Have I managed to purchase some odd OEM version that will not support multiple namespaces or is there a way to unlock/reset the functionality on these?

Using sedutil-cli and nvme-cli I was able to tinker a bit; wiped the unknown SED password with a PSID wipe; deleted and recreated the one namespace at various sizes and switching back and forth between 512B and 4096B sector sizes. All seems to work fine, except for only supporting 1 namespace. Am I screwed?

If I should start a new thread for this, let me know.

 

[gb00s]

:
Using sedutil-cli and nvme-cli I was able to tinker a bit; wiped the unknown SED password with a PSID wipe; deleted and recreated the one namespace at various sizes and switching back and forth between 512B and 4096B sector sizes. All seems to work fine, except for only supporting 1 namespace. Am I screwed?
:

What is nvme id-ctrl /dev/nvmeX -H | grep nn saying?

Edit: Btw from what I read is that the MZ1L23T8HBLA-00AMV is a OEM variant of the MZ1L23T8HBLA-00A07
EDit: What firmware is on?

 

[DaveP]

Firmware on all 4 is GDC79M4Q. And nn reports 1.

 

[gb00s]

If 'nn' reports 1 then there is just 1 namespace. That's the OEM config. I'm not sure if you can upgrade an OEM firmware to original Samsung firmware that may gives you 32 namespaces.

 

[DaveP]

If no reports one then there is just 1 namespace. That's the OEM config. I'm not sure if you can upgrade an OEM firmware to original Samsung firmware that may gives you 32 namespaces.

Not the answer I was hoping, but does that seem to be what these are, some OEM version that wasn't meant for normal resale?

Using nvme-cli, is it possible to try the current, standard PM9A3 firmware in a firmware slot and if it doesn't like it would just reject it or could that brick it?

 

[DaveP]

I tried a couple different PM9A3 firmware files and they all get the same error:

root@p:/opt/pm9a3-fw# nvme fw-download -f General_PM9A3_M.2_GDC7502Q_Noformat.bin /dev/nvme0
Firmware download success
root@p:/opt/pm9a3-fw# nvme fw-commit -s 2 -a 0 /dev/nvme0
NVMe status: Firmware Activation Prohibited: The image specified is being prohibited from activation by the controller for vendor specific reasons(0x113)
Multiple Update Detected (MUD) Value: 0

 

[DarkServant]

I've never read from someone who has done a FW flash to an OEM (vendor-locked) drive with a standard firmware and succeeded...
I see a lot of SSD's on ebay which are "vendor-locked" (sixth digit/character not 0 where it should be, only some pm17xx have a B instead in think). Be careful what you buy.

Probably is there a way when you go in-depth and tinker with "JTAG hacking", which is way more risky and elaborate than upload a firmware, which will simply be rejected if the digitally signed part does not match.
Firmware updates can be critical, and on SSD's they are special important, a look at some changelog XLS shows why. Many changes do not affect you, others may send shiver down your spine, but i do not have a changelog for every FW-version and SSD.

It will only get more complex as the bits-per-cell grow and the layer-count increases.

PS: latest f/w is GDC7802Q for the m.2 pm9a3 ...taken from HDDGuru
BTW: interesting how they try to replace 3DXpoint with some pSLC drives, which are quite fast and durable -> Innogrit N3X, Phison X200Z