Used SM863 slow write performance issue

[truth_is_an_opinion]

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.



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]

Flash the drive firmware if it is old. There was an update a while back that disables some endurance protection mechanism that is causing a lot of speed-related issues at this point of the drives' life.

Samsung GB57 for model number(s) MZ7KM240HAGR00D3, MZ7KM480HAHP00D3, MZ7KM960HAHP00D3, MZ7KM1T9HAJM00D3, MZ8KM240HAGR00D3, MZ8KM480HAHP00D3 and MZ8KM960HAJH00D3. | Driver Details | Dell US

 

[truth_is_an_opinion]

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]

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]

A Secure Erase might help (the NAND/metadata could be "constipated").
=====
"This town needs an enema." -- The Joker

 

[Marsh]

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]

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]

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]

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:

ID	Description	Raw	Raw (hex)	Normalized	Worst	Threshold	Status
5	Reallocated Sector Count	0 -> 256	0x0 -> 0x100	100 -> 96	100 -> 96	10	OK
179	Used Reserved Block Count (total)	0 -> 256	0x0 -> 0x100	100 -> 96	100 -> 96	10	OK
180	Unused Reserved Block Count (total)	7705 -> 7449	0x1e19 -> 0x1d19	100 -> 96	100 -> 96	0	OK
182	Erase Fail Count (total)	0 -> 256	0x0 -> 0x100	100 -> 96	100 -> 96	0	OK

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

 

[marchenko]

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]

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