Drive performance testing (version 2.6.5) for UNRAID 5 thru 6.4


Recommended Posts

Obviously my single SSD drive's speed is reporting wrong speeds. Anyone else? It is the last drive in this list.

 

sdh: Samsung SSD 840 EVO 120GB S1D5NSBFB10859N  120 GB   118 MB/sec avg

 

If you use the -l or --log option, it'll create a debug log file that I can analyze. Please attach it here or email it to jbartlett at strangejourney.net

 

I'll run it again and use the log option. Hold tight.

 

Log sent to your email. Thanks!

 

EDIT: What's really weird is when I copy a single large file to it the speed tops out of 112MB/sec. Just like the results I get when writing to the array. It is an UNassigned drive. Not part of the array at all. I do have an old speedtest report from late last year and that same drive was getting around 480MB-500MB/sec speeds. So this may have nothing to do with the speedtest script at all. Maybe post a thread in the V6 support area.

 

I can tell you that it's not my script. Try checking the SMART values on the drive.

 

The first two checks returned 496 & 507 MB/s and then dropped down to the 70's after that.

 

Try running the following:

diskspeed.sh -s 51 -x sda,sdb,sdc,sdd,sde,sdf,sdg,sdh,sdi,sdj,sdk,sdl

*note* remove the sd? value current assigned to the SDD

 

This will scan it at every 2% and exclude all the other drives. This may give a better picture where things start to go wonky. Really for informational purposes only.

 

You can fine tune further with the following which is the same command the script uses:

dd if=/dev/sdh of=/dev/null bs=1GB count=1 skip=0 iflag=direct

 

The skip value is how many 1GB blocks to skip before reading.

Link to comment

Obviously my single SSD drive's speed is reporting wrong speeds. Anyone else? It is the last drive in this list.

 

sdh: Samsung SSD 840 EVO 120GB S1D5NSBFB10859N  120 GB   118 MB/sec avg

 

If you use the -l or --log option, it'll create a debug log file that I can analyze. Please attach it here or email it to jbartlett at strangejourney.net

 

I'll run it again and use the log option. Hold tight.

 

Log sent to your email. Thanks!

 

EDIT: What's really weird is when I copy a single large file to it the speed tops out of 112MB/sec. Just like the results I get when writing to the array. It is an UNassigned drive. Not part of the array at all. I do have an old speedtest report from late last year and that same drive was getting around 480MB-500MB/sec speeds. So this may have nothing to do with the speedtest script at all. Maybe post a thread in the V6 support area.

 

I can tell you that it's not my script. Try checking the SMART values on the drive.

 

The first two checks returned 496 & 507 MB/s and then dropped down to the 70's after that.

 

Try running the following:

diskspeed.sh -s 51 -x sda,sdb,sdc,sdd,sde,sdf,sdg,sdh,sdi,sdj,sdk,sdl

*note* remove the sd? value current assigned to the SDD

 

This will scan it at every 2% and exclude all the other drives. This may give a better picture where things start to go wonky. Really for informational purposes only.

 

You can fine tune further with the following which is the same command the script uses:

dd if=/dev/sdh of=/dev/null bs=1GB count=1 skip=0 iflag=direct

 

The skip value is how many 1GB blocks to skip before reading.

 

Could be that flaky firmware, since it is an Samsung 840 SSD. I'll have to install it in a Windows machines and see if I can update the firmware. Don't think there is a way you can do it through Linux.

 

root@SUN:/boot/scripts# dd if=/dev/sdh of=/dev/null bs=1GB count=1 skip=0 iflag=direct

1+0 records in

1+0 records out

1000000000 bytes (1.0 GB) copied, 2.30283 s, 434 MB/s

root@SUN:/boot/scripts#

 

Link to comment

Rebooted the server, made sure there were no connections to it and ran another default test and results were very low on that one SSD. There's only 15GB on the drive itself and I planned on using it but don't want to use it if there's something wrong. Since the drive is in a rack mount I can easily pull it out and try to update the firmware. I do also have a Samsung 850 SSD I can install and test that too.

 

Maybe I'll see if there is a way to update the firmware via command line in Linux.

 

 

I ran this command. I included all my drives EXCEPT SDH, which is the SSD. I assume that's what it is supposed to do.

 

root@SUN:/boot/scripts# diskspeed.sh -s 51 -x sdm,sdn,sdp,sdo,sdi,sdj,sdk,sdl,sdb,sdc,sdd,sde,sdf,sdg

 

diskspeed.sh for UNRAID, version 2.4

By John Bartlett. Support board @ limetech: http://goo.gl/ysJeYV

 

/dev/sdb (Disk : Skipped
/dev/sdc (Disk 9): Skipped
/dev/sdd (Disk 10): Skipped
/dev/sde (Disk 11): Skipped
/dev/sdf (Disk 12): Skipped
/dev/sdg: Skipped
/dev/sdh: 155 MB/sec avg <--- SSD drive Samsung 840 120GB
/dev/sdi (Disk 4): Skipped
/dev/sdj (Disk 5): Skipped
/dev/sdk (Disk 6): Skipped
/dev/sdl (Disk 7): Skipped
/dev/sdm (Parity): Skipped
/dev/sdn (Disk 1): Skipped
/dev/sdo (Disk 3): Skipped
/dev/sdp (Disk 2): Skipped

 

 

 

Link to comment

Ouch. What in the world would do that to an SSD drive? No firmware updating tonight.

 

That’s a known issue with the 840 EVO, old data becomes slow, what the updated firmware does is from time to time re-writes old data, how this affects the SSD wear I don’t know.

Link to comment

Ouch. What in the world would do that to an SSD drive? No firmware updating tonight.

 

That’s a known issue with the 840 EVO, old data becomes slow, what the updated firmware does is from time to time re-writes old data, how this affects the SSD wear I don’t know.

 

There's only 15GB of data on it. I can remove everything from the drive and re-test it.

 

Link to comment

There's only 15GB of data on it. I can remove everything from the drive and re-test it.

 

I should have said cells not written for some time, the issue with this model is that cells that stay unchanged for a long time become slow, usually more noticeable when reading old data, but empty unused cells will be slow as well, and I don’t know if the firmware update will fix this, because afaik it tries to mitigate the issue by periodically rewriting occupied cells.

 

For this test if you completely filled the ssd with fresh data you would should get a better result.

Link to comment

There's only 15GB of data on it. I can remove everything from the drive and re-test it.

 

I should have said cells not written for some time, the issue with this model is that cells that stay unchanged for a long time become slow, usually more noticeable when reading old data, but empty unused cells will be slow as well, and I don’t know if the firmware update will fix this, because afaik it tries to mitigate the issue by periodically rewriting occupied cells.

 

For this test if you completely filled the ssd with fresh data you would should get a better result.

 

It's only 120GB, so I'll fill it up and see what happens. I hope this isn't what we have to look forward to using SSD's in the unraid OS.

Link to comment

It's only 120GB, so I'll fill it up and see what happens. I hope this isn't what we have to look forward to using SSD's in the unraid OS.

 

This is a Samsung issue, only on the 840 EVO.

 

Amazing. Filled the drive up, ran the speedtest just one that drive:

 

/dev/sdh: 401 MB/sec avg

 

Johnnie, you said this is just inherent to the Samsung 840 EVO drive. By flashing the new firmware, will this fix the problem. I guess they fixed this problem in the Samsung 850 EVO models.

 

I wonder what this will do to laptops that have data stored on the drive for a long time. Would it just get slower and slower? Trying to understand the problem better, to see if I can rack it around my little brain.

 

Thanks again.

 

Link to comment

Johnnie, you said this is just inherent to the Samsung 840 EVO drive. By flashing the new firmware, will this fix the problem. I guess they fixed this problem in the Samsung 850 EVO models.

 

The new firmware re-writes the data from time to time to keep it “fresh”, it’s kind of a workaround but it works, it may however increase SSD wear, since it keeps re-writing existing data.

 

The 850 Evo uses different nand flash and is not affected.

Link to comment

Johnnie, you said this is just inherent to the Samsung 840 EVO drive. By flashing the new firmware, will this fix the problem. I guess they fixed this problem in the Samsung 850 EVO models.

 

The new firmware re-writes the data from time to time to keep it “fresh”, it’s kind of a workaround but it works, it may however increase SSD wear, since it keeps re-writing existing data.

 

The 850 Evo uses different nand flash and is not affected.

 

I know this may be beating a dead horse now but was Samsung and consumers aware of this issue before they started selling these drives with the NAND chips? I wonder if laptop users experience performance issues. What an odd fix. The drive read/writing data by itself to keep performance up but also decreasing the drives life. Thanks for the explanation. I do have some Samsung 850's, so I'll replace that 840.

Link to comment

No, the issue was not known (at least not public) when the drives were released.

 

I guess it's not that bad after all. As long as you don't have to rewrite the drive manually.

The lifetime is probably not affected as much as you think.

 

Then, who can say what the 850 EVO's are doing in their firmware? Maybe the same trick?  ???

IMHO, your fine with the 840 and if you experience degradation of the cells one day, you will

probably be happy to replace that drive.

 

 

Link to comment

No, the issue was not known (at least not public) when the drives were released.

 

I guess it's not that bad after all. As long as you don't have to rewrite the drive manually.

The lifetime is probably not affected as much as you think.

 

Then, who can say what the 850 EVO's are doing in their firmware? Maybe the same trick?  ???

IMHO, your fine with the 840 and if you experience degradation of the cells one day, you will

probably be happy to replace that drive.

 

Went from 500MB/sec speeds to 100MB/sec speeds. And most of the time the drive wasn't being used sitting idle. Hey, maybe the newer technology has worse bugs we haven't seen yet. Who knows.

 

Link to comment
  • 2 weeks later...
  • 2 weeks later...

Still fixing issues in the script to support UNRAID 6.2. It's more than just not working, it's totally borked in 6.2. I have to change how the disk inventory is done as well as modifications in the commands in Slackware 4.4 (UNRAID 6.2) vs 4.1 (UNRAID 6.1).

 

Slowly working out the issues and coding to be compatible with 6.1 & 6.2 as time presents itself.

 

I've also started working on a UNRAID 6.2 plugin version that will map out the controllers & the drives connected to them, auto detecting the physical drive geometry, speed heat maps, multiple drives testing at the same time by controller, etc.

Link to comment

Still fixing issues in the script to support UNRAID 6.2. It's more than just not working, it's totally borked in 6.2. I have to change how the disk inventory is done as well as modifications in the commands in Slackware 4.4 (UNRAID 6.2) vs 4.1 (UNRAID 6.1).

 

Slowly working out the issues and coding to be compatible with 6.1 & 6.2 as time presents itself.

 

I've also started working on a UNRAID 6.2 plugin version that will map out the controllers & the drives connected to them, auto detecting the physical drive geometry, speed heat maps, multiple drives testing at the same time by controller, etc.

 

Sounds great!  8)

Link to comment
  • 4 weeks later...

"To see a graph of the drive's speeds, please browse to the current

directory and open the file diskspeed.html in your Internet Browser

application."

 

There is no diskspeed.html file after running the script. I am running the file from the unRAID flash drive (/boot/diskspeed.sh). I also tried putting it in it's own folder. I'm running the script via telnet with root login so permissions should not be an issue.

 

Can't find a single post having this issue, so I'm assuming some kind of user error? Running 6.1.9.

Link to comment
  • 3 weeks later...

Im getting the error "Error: There are disabled drives in the array"

 

Any way to force the script to run? I dont have any disabled drives on my array to my knowledge :S

The script isn't compatible with 6.2 - the system apps output text differently and the way the script inventoried the drives isn't compatible either. I'm working on making it compatible with 6.19 and below as well as 6.2 and above but my time is limited.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.