- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-26-2022 07:06 PM (Last edited 11-26-2022 08:46 PM ) in
Monitors and Memory970 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)?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
11-26-2022 08:54 PM in
Monitors and Memory970 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)?

