Used SM863 slow write performance issue

Notice: Page may contain affiliate links for which we may earn a small commission through services like Amazon Affiliates or Skimlinks.

truth_is_an_opinion

New Member
Oct 8, 2023
7
4
3
Hi all, I'm new to self hosting, so I hope I'm providing relevant information for my issue!

I just got some used SM863's off of eBay, and in the course of testing them, I keep getting very low write speeds. The SMART data says that they've been powered on for 60k hours, but only have 2% wear out.

I have a Dell PowerEdge T430 16 SFF bay with an HBA330 card, with drives installed in the bays and using the internal SATA port (8087 to 4x SATA). The ones through the HBA seem to offer better performance, and so I have included the screenshot of CrystalDiskMark in Windows running of a different drive.

CrystalDiskMark SM863 HBA.png

What I get: 160MB/s sequential writes.
What I expected: based on ServeTheHome testing I was expecting sequential writes of 400MB/s+.

I have also done similar tests in Proxmox (in the host's console with dd) and in an Ubuntu VM (using dd and KDiskMark). Both got similar results to CrystalDiskMark.

I'm happy to run whatever tests you might suggest if it will help!

Cheers :)
 

mmk

Active Member
Oct 15, 2016
104
39
28
Czech Republic
  • Like
Reactions: truth_is_an_opinion

truth_is_an_opinion

New Member
Oct 8, 2023
7
4
3
Hi mmk, thanks for your response, I see from this post you're the one to ask about this :) Indeed my drives are on firmware GB32.

However, I seem to have MZ7KM960HAHP00D6 drives. I see this other post someone else had these but they never reported back.

In the fist post, the mentioned solution seems pretty fraught, is there anyway that you know of to use the official Dell executables or the Samsung DC Toolkit? If it helps, I believe I have Dell OEM drives.
 

truth_is_an_opinion

New Member
Oct 8, 2023
7
4
3
I just tried using the linked Windows executable even with the mismatched versions, but sadly it picks up on this and doesn't do anything.
 

UhClem

just another Bozo on the bus
Jun 26, 2012
446
258
63
NH, USA
A Secure Erase might help (the NAND/metadata could be "constipated").
=====
"This town needs an enema." -- The Joker
 

Marsh

Moderator
May 12, 2013
2,654
1,501
113
I had the same experience with slow write.

I sent back the 4 Samsung SSD, life is too short to deal with slow write.
Lots of cheap SSD nowadays.
 

mmk

Active Member
Oct 15, 2016
104
39
28
Czech Republic
A secure erase might indeed help for a while. This is however a fairly unreliable fix for the various Samsungs of this era: the erase may help for a year or a day. This is not the only drive model affected by these issues..

Sorry, don't know the details of exact drive models and how they can be updated. May be worthwhile digging some more on the Dell support site, perhaps under different hardware models. The D6 drives were however normal drives shipped with Poweredge systems so they _should_ be updateable.
 

truth_is_an_opinion

New Member
Oct 8, 2023
7
4
3
Thanks for the input everyone, I'll update with what I end up trying and the results!

@mmk, good to know, I might try and change some of the files in the Windows .exe based on the EBLEND link to get around the model/HW ID check if I can't find any official firmware.
 

truth_is_an_opinion

New Member
Oct 8, 2023
7
4
3
Success (at a cost)! I followed the approach EBLEND suggests and it worked. Note that I only had one of the relevant drives installed at the time so all results are definitely for it:
  1. Take Dell firmware update software, in my case GB57, and download the Windows EXE.
  2. Extract the EXE, resulting in a bunch of tools, and a payload directory containing the firmware (GB57.fwh in this case, note that the sofware appears to check the file name while executing to see if it matches the firmware header which records compatible drives).
  3. Run the given command SASDUPIE.exe -u -s "%cd%\payload" -f -o update.xml -debug debug.log from the root of the extracted EXE with an admin CMD, with the expectation that it will fail, and inspect the created debug log.
  4. Find the hardware ID of your drive, 104455 in my case, and the existing firmware if you don't know already, GB32 in my case.
  5. Edit the firmware file with a hex editor of your choice to change the Dell header.
    1. The header format is a variable length (relevant for the hdparm approach), the important bits in order are ignoring the fluff:
      1. New firmware version.
      2. Minimum firmware version.
      3. Number of drives supported by the firmware.
      4. A list of pairs of drive models and associate hardware IDs.
    2. Change the minimum firmware to the current version (in my case GB50 was listed, so it was easy, I don't know what one would do if the string lengths don't match).
    3. Change the drive model and hardware ID (so I changed ..D3 to ..D6 and 104539 to 104455). I don't know if the model was important but I did it anyway.
  6. Replace the firmware file with your new one in the same location, making sure to use the same file name.
  7. Run the given command SASDUPIE.exe -u -s "%cd%\payload" -f -o update.xml -debug debug.log again.
  8. This should succeed!
  9. I then powered off the machine, removed the drive, put it back in, and turned the machine on.
The result is that the firmware has been updated (as viewed with SMART tools), and the sequential writes are above 400MB/s as expected!

Here's the cost. As mentioned in another thread by a user who did the same but with hdparm, the update results in 256 reallocated sectors. Here are the SMART entries that changed:

IDDescriptionRawRaw (hex)NormalizedWorstThresholdStatus
5Reallocated Sector Count0 -> 2560x0 -> 0x100100 -> 96100 -> 9610OK
179Used Reserved Block Count (total)0 -> 2560x0 -> 0x100100 -> 96100 -> 9610OK
180Unused Reserved Block Count (total)7705 -> 74490x1e19 -> 0x1d19100 -> 96100 -> 960OK
182Erase Fail Count (total)0 -> 2560x0 -> 0x100100 -> 96100 -> 960OK

So, my final question is: assuming that the firmware update is successful, how bad of a cost is it if 256 blocks are lost? I got these pretty cheap, but they've been imported so the return fees will be a lot and I'll lose the import duty, so if the downside of 256 blocks is minimal, I'll update the rest I have and live with it.

Cheers
 
Last edited:

marchenko

New Member
Jan 13, 2024
2
0
1
Success (at a cost)! I followed the approach EBLEND suggests and it worked. Note that I only had one of the relevant drives installed at the time so all results are definitely for it:....
tried this method, for some reason it wont show device id in debug.log. Tried changing device id to 000000 as well as FW version / model tweak, but still says No Device Found.

Did you set your controller in legacy or AHCI mode? Any other specifics?
 

truth_is_an_opinion

New Member
Oct 8, 2023
7
4
3
Hmmm, that sucks that it doesn't show up, I don't have any suggestions since it worked for me.

I never did anything secific as far as I know, I believe the HBA has always been using SATA 3.0