Original topic:

970 EVO Plus not persisting writes to first 32K of drive ... firmware bug?

(Topic created: 11-26-2022 07:06 PM)
anathema
Constellation
Options
Monitors and Memory

970 EVO Plus 2TB

Model: MZ-V7S2T0

Product Date: 2202 08 09

Firmware: 4B2QEXM7

I've owned several Samsung SATA SSDs and been very happy with them. This is my first NVMe drive and I expected for it to be a breeze. However, I've found myself struggling over the last many days to figure out why my NVMe drive is not persisting some writes. I'm still investigating some of the parameters around this. I hope that this is just some kind of misconfiguration (I haven't changed anything from defaults though), and not a reflection on the quality of this Samsung product. Either way its frustrating to be wasting time on this, when it all should just work (never had any problems with the SATA SSDs).

This behavior is being observed from a Ubuntu 22.10 live cd, which uses the 5.19 linux kernel, on a ThinkPad P51. The first writes of the first 32K of the drive were successful, as I formatted the drive for use initially. I didn't write to the first 32K for a couple weeks later, so I don't know if writes done shortly after the initial write would have successfully persisted. I've also tried using the linux command "blkdiscard" in those sectors to see if I could just erase them, with no luck. The drive apparently returns success for the writes and discards, but doesn't actually do them. I have rebooted several times and the behavior persists, though I have not done a cold boot yet. Even if that changed things, I'd still worry about when this issue might pop back up.

I have used blkdiscard to successfully delete the 32K-36K byte range. I've also done "dd if=/etc/mime.types of=/dev/nvme0n1 seek=60" and seen that the first 2K of the file are not written to the 30-32K byte range, but after the 32K byte mark the file is persisted to the NVMe.

The only way I could see this being a "feature" is as part of some kind of boot sector protection mechanism. However, that kind of thing should be off by default and I've never heard of that as a drive feature anyway. I've looked at various NVMe tools in linux but don't see anything that might help.

Anyone have any clues here? Does Samsung support see this board or how do I escalate this (ie is Elite/Extended Warranty / Remote Support / Protection Plus number the right number to call)?

0 Likes
1 Reply
anathema
Constellation
Options
Monitors and Memory

970 EVO Plus 2TB

Model: MZ-V7S2T0

Product Date: 2202 08 09

Firmware: 4B2QEXM7

I've owned several Samsung SATA SSDs and been very happy with them. This is my first NVMe drive and I expected for it to be a breeze. However, I've found myself struggling over the last many days to figure out why I can't overwrite the first 32K of the drive. I hope that this is just some kind of misconfiguration (I haven't changed anything from defaults though), and not a reflection on the quality of this Samsung product. Either way its frustrating to be wasting time on this, when it all should just work (never had any problems with the SATA SSDs).

This behavior is being observed from a Ubuntu 22.10 live cd, which uses the 5.19 linux kernel, on a ThinkPad P51. The first writes of the first 32K of the drive were successful, as I formatted the drive for use initially. I didn't write to the first 32K for a couple weeks later, so I don't know if writes done shortly after the initial write would have successfully persisted. I've also tried using the linux command "blkdiscard" in those sectors to see if I could just erase them, with no luck. The drive apparently returns success for the writes and discards, but doesn't actually do them. I have rebooted several times and the behavior persists, though I have not done a cold boot yet. Even if that changed things, I'd still worry about when this issue might pop back up.

I have used blkdiscard to successfully delete the 32K-36K byte range. I've also done "dd if=/etc/mime.types of=/dev/nvme0n1 seek=60" and seen that the first 2K of the file are not written to the 30-32K byte range, but after the 32K byte mark the file is persisted to the NVMe.

The only way I could see this being a "feature" is as part of some kind of boot sector protection mechanism. However, that kind of thing should be off by default and I've never heard of that as a drive feature anyway. I've looked at various NVMe tools in linux but don't see anything that might help.

Anyone have any clues here? Does Samsung support see this board or how do I escalate this (ie is Elite/Extended Warranty / Remote Support / Protection Plus number the right one to call)?