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


Recommended Posts

Finished my first lot of testing today.

 

 

/dev/sdb (Disk 1): 119 MB/sec avg

/dev/sdc (Disk 3): 171 MB/sec avg

/dev/sdd (Disk 2): 112 MB/sec avg

/dev/sde (Parity): 143 MB/sec avg

/dev/sdf (Disk 7): 120 MB/sec avg

/dev/sdg (Disk 5): 120 MB/sec avg

/dev/sdh (Disk 8): 118 MB/sec avg

/dev/sdi (Disk 6): 116 MB/sec avg

/dev/sdj (Cache): 382 MB/sec avg

/dev/sdk (Disk 4): 92 MB/sec avg

 

Am going to run a extended smart test on sdk as there is no reason for the drive to be that much slower than the rest.

 

Edit : "Seagate Barracuda LP 2 TB 5900RPM SATA 3 GB/s" that may have something to do with the speed lol.

rsz_chart.png.df3fcd55ac799cc293010053c4134adf.png

rsz_chart_1.png.82749a34986b95dd4f8a23d3ddf53721.png

chart_3.png.e258ba9118dcb746c0736413040c8559.png

Link to comment

Finished my first lot of testing today.

 

 

/dev/sdb (Disk 1): 119 MB/sec avg

/dev/sdc (Disk 3): 171 MB/sec avg

/dev/sdd (Disk 2): 112 MB/sec avg

/dev/sde (Parity): 143 MB/sec avg

/dev/sdf (Disk 7): 120 MB/sec avg

/dev/sdg (Disk 5): 120 MB/sec avg

/dev/sdh (Disk 8): 118 MB/sec avg

/dev/sdi (Disk 6): 116 MB/sec avg

/dev/sdj (Cache): 382 MB/sec avg

/dev/sdk (Disk 4): 92 MB/sec avg

 

Am going to run a extended smart test on sdk as there is no reason for the drive to be that much slower than the rest.

 

Edit : "Seagate Barracuda LP 2 TB 5900RPM SATA 3 GB/s" that may have something to do with the speed lol.

 

I recently ran this after adding a new disk. For some reason it reported speed of 60ish with everything else well over 160. Kind of had me worried so I ran it again. Second run it was in the middle of the pack as I would expect.

Link to comment
  • 3 weeks later...

So,

 

I'm trying to figure out why unrars aren't hitting cache speed (and unrar'ing seems to choke the system - everything *should* be on cache, but system stats during unrar are more consistent with array drive speeds and WebGui becomes unresponsive, and nope, doesn't seem to be CPU or RAM).

 

In the process, I got this interesting result from the diskspeed graph...

 

CLI output is

 

diskspeed.sh for UNRAID, version 2.4

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

 

/dev/sdb (Cache): 558 MB/sec avg

/dev/sdc (Disk 4): 158 MB/sec avg

/dev/sdd (Disk 1): 159 MB/sec avg

/dev/sde (Disk 2): 163 MB/sec avg

/dev/sdf (Parity): 158 MB/sec avg

/dev/sdg (Disk 3): 156 MB/sec avg

 

 

and then, that confusing little line on the bottom - is it a bug in the script, or is there something else at play I'm missing here ?

diskspeed_graph.jpg.8fe1e0ab38873099fa3923b5a9c1e5c3.jpg

Link to comment

Are you trimming your SSD? in my experience Samsung SSDs writes are terrible without trim.

 

Thanks for the hint - normally, I *should* be... what I don't quite get is if I borked my config somehow, and ended up with a parity-protected cache drive or something stupid, or if there's something else at play that generates that bottom result.

Link to comment

 

 

Thanks for the hint - normally, I *should* be... what I don't quite get is if I borked my config somehow, and ended up with a parity-protected cache drive or something stupid, or if there's something else at play that generates that bottom result.

 

No, your SSD is assigned to cache, so it can't be part of the array, the correct read speed is the one shown on the graph, but by what you describe what you have are slow writes, by default cache is not trimmed, you have to install the dynamix trim plugin.

 

 

Link to comment

No, your SSD is assigned to cache, so it can't be part of the array, the correct read speed is the one shown on the graph, but by what you describe what you have are slow writes, by default cache is not trimmed, you have to install the dynamix trim plugin.

 

Awesome, thanks !

Link to comment
  • 4 weeks later...
  • 4 weeks later...

So this utility is giving me good read speeds on all my drives (90MB/s for green drives, 120MB/s for red drives, 400MB/s for SSD cache)!

 

However, my write speeds are terrible... 20MB/s or so. Copying large files using Midnight Commander.

 

Any ideas off the top of your heads what may be causing this?

 

PS: Great utility!

Link to comment

So this utility is giving me good read speeds on all my drives (90MB/s for green drives, 120MB/s for red drives, 400MB/s for SSD cache)!

 

However, my write speeds are terrible... 20MB/s or so. Copying large files using Midnight Commander.

 

Any ideas off the top of your heads what may be causing this?

 

PS: Great utility!

Writing utilizes the parity drive so it'll always be worse off. There's an option with 6.2 to speed up writes by having all drives spun up but I don't know if it's in earlier versions.

Link to comment
  • 3 weeks later...

I am just about to upgrade my server with a Dell Perc H200, currently my MB (Intel S5500WB) only supports SATA 300 and the Perc H200 should give me SATA 600 while also allowing expansion options down the road.

 

I am running unRAID 6.2 RC4 at the moment and I know the script currently does not support 6.2.X. I am wondering, is it worth my while waiting on an update to this script in the near future to test the before/after difference in drive speed or will you be waiting until unRAID 6.2 Final prior to releasing an updated script?

 

Thanks a million for you work on this.

 

 

 

 

Link to comment
  • 4 weeks later...

Please test to see if it's operating as desired for you.

 

Thanks, used it on my test server, graph is correct but results below are not.

 

Edit: results on the console are correct:

 

diskspeed.sh for UNRAID, version 2.6 beta
By John Bartlett. Support board @ limetech: http://goo.gl/ysJeYV

/dev/sdb: 223 MB/sec avg
/dev/sdc: 221 MB/sec avg
/dev/sdd: 221 MB/sec avg
/dev/sde: 221 MB/sec avg
/dev/sdf: 222 MB/sec avg
/dev/sdg: 223 MB/sec avg
/dev/sdh: 222 MB/sec avg
/dev/sdi (Disk 1): 443 MB/sec avg
/dev/sdj: 222 MB/sec avg
/dev/sdk (Disk 2): 443 MB/sec avg
/dev/sdl: 441 MB/sec avg
/dev/sdm: 444 MB/sec avg
/dev/sdn: 443 MB/sec avg
/dev/sdo: 443 MB/sec avg
/dev/sdp: 441 MB/sec avg
/dev/sdq: 443 MB/sec avg

chart.png.fe32e70cfd7fdb12e728199002a138c3.png

Link to comment

It doesn't yet identify Parity 2 or the 2nd & higher cache drives so it'll list those by their SDx identifier. Still need to figure out how to identify those.

 

Currently, Parity2 is disk 29.  I don't know if it always will be though.  That's MAX_ARRAYSZ - 1 perhaps.  The 'vars' have it, and the Cache drives (cache, cache2, cache3, etc), with their drive symbols.

Link to comment

It doesn't yet identify Parity 2 or the 2nd & higher cache drives so it'll list those by their SDx identifier. Still need to figure out how to identify those.

 

Currently, Parity2 is disk 29.  I don't know if it always will be though.  That's MAX_ARRAYSZ - 1 perhaps.  The 'vars' have it, and the Cache drives (cache, cache2, cache3, etc), with their drive symbols.

You're describing PHP variables I believe, this is a bash script.

Link to comment

It doesn't yet identify Parity 2 or the 2nd & higher cache drives so it'll list those by their SDx identifier. Still need to figure out how to identify those.

 

Currently, Parity2 is disk 29.  I don't know if it always will be though.  That's MAX_ARRAYSZ - 1 perhaps.  The 'vars' have it, and the Cache drives (cache, cache2, cache3, etc), with their drive symbols.

You're describing PHP variables I believe, this is a bash script.

While I'd like to learn PHP, I haven't yet.  I only use bash here so far, and not very good at it, get very frustrated with the picky syntax.

 

I haven't parsed the 'vars' myself, but looks straightforward, very consistent construction, look at vars.txt in the diagnostics.  I'm sure there's code to do it somewhere already, and code you can base it on in bonienl's work, and probably others too.  If I were doing it, I'd probably skip creating an array of the drives and their info, just grab the vars as a string blob and string search it, since you only need minimal info from it.

Link to comment

It doesn't yet identify Parity 2 or the 2nd & higher cache drives so it'll list those by their SDx identifier. Still need to figure out how to identify those.

 

Currently, Parity2 is disk 29.  I don't know if it always will be though.  That's MAX_ARRAYSZ - 1 perhaps.  The 'vars' have it, and the Cache drives (cache, cache2, cache3, etc), with their drive symbols.

You're describing PHP variables I believe, this is a bash script.

While I'd like to learn PHP, I haven't yet.  I only use bash here so far, and not very good at it, get very frustrated with the picky syntax.

 

I haven't parsed the 'vars' myself, but looks straightforward, very consistent construction, look at vars.txt in the diagnostics.  I'm sure there's code to do it somewhere already, and code you can base it on in bonienl's work, and probably others too.  If I were doing it, I'd probably skip creating an array of the drives and their info, just grab the vars as a string blob and string search it, since you only need minimal info from it.

 

I'd love to get the vars and parse it out, I just can't think of a way yet to be able to guarantee it. For example, I could use wget to fetch the var page but if they have security in place to access the admit, it wouldn't allow it.

 

I'm using the output mdcmd and it lists the Parity 2 drive in slot 29 but no mention of the cache drives.

Link to comment

It doesn't yet identify Parity 2 or the 2nd & higher cache drives so it'll list those by their SDx identifier. Still need to figure out how to identify those.

 

Currently, Parity2 is disk 29.  I don't know if it always will be though.  That's MAX_ARRAYSZ - 1 perhaps.  The 'vars' have it, and the Cache drives (cache, cache2, cache3, etc), with their drive symbols.

You're describing PHP variables I believe, this is a bash script.

While I'd like to learn PHP, I haven't yet.  I only use bash here so far, and not very good at it, get very frustrated with the picky syntax.

 

I haven't parsed the 'vars' myself, but looks straightforward, very consistent construction, look at vars.txt in the diagnostics.  I'm sure there's code to do it somewhere already, and code you can base it on in bonienl's work, and probably others too.  If I were doing it, I'd probably skip creating an array of the drives and their info, just grab the vars as a string blob and string search it, since you only need minimal info from it.

 

I'd love to get the vars and parse it out, I just can't think of a way yet to be able to guarantee it. For example, I could use wget to fetch the var page but if they have security in place to access the admit, it wouldn't allow it.

 

I'm using the output mdcmd and it lists the Parity 2 drive in slot 29 but no mention of the cache drives.

 

When you use wget to read localhost (or 127.0.0.1) then no username/password verification is required. This allows you to run a script on the system and let it inquire locally.

 

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.