Jump to content
  • 0

Read Striping not working at all?

danielb

Asked by danielb,

 Share

Question

danielb Newbie

danielb

Posted
Posted

Hi

I have 1x3TB WD RED + 1x 4TB WD RED, and with read striping enabled, drive pool insists on reading only from the slightly faster 4TB HDD. I'm copying a 6GB file to a RAMDisk, so that is not a bottleneck. I get around 160MB/S with striping enable/disabled, that's the max speed of the 4TB drive. During the transfer i can see for brief moments the 3TB hdd showing up in the performance tab, but it goes away almost instantly!

I understand i wont get the total sum of read speed of both HDD, but i expected a improvement, even if only 10MB/s or something, at this time i don't see ANY improvement.

OS Windows server 2016

Folder duplication is enabled 2x on the file i was testing.

17 answers to this question

Recommended Posts

  • 0
Umfriend Advanced Member

Umfriend

Posted
Posted

As far as I can tell, read striping only works when you are reading LOTS of files, not a single large file. If, for instance, I browse through a folder with lots of pictures, then the thumbnails come up way quicker with read striping enabled. I *think* this is because DP is file based and opens I/O to individual files located on an individual disk. If many files are to be read concurrently, then it may initiate some I/O on one and some on the other HDD.

  • 0
Jaga Advanced Member

Jaga

Posted
Posted

I was all set to agree with you Umfriend (actually had it typed in already), until I re-read the docs about read striping.  Large sequential I/O uses block-based read striping, so it should have kicked in for danielb.

@danielb - have you benchmarked each drive to see if there's much of a difference?  It's possible that one actually is performing better than the other for some reason, and Drivepool picks up on that.

 

Quote

StableBit DrivePool utilizes a number of read striping algorithms, depending on the situation.

For large sequential I/O, such as large file copying, read striping will utilize a block based algorithm, maximizing the use of each disk and minimizing disk context switches.

For random non-sequential I/O read striping always sends the request to the disk with the least outstanding requests. Because seek times can be high in this scenario, StableBit DrivePool tries to switch disk contexts often.

For slow non-concurrent I/O read striping passively measures the speed of each disk and dynamically switches the the fastest disk.

 

What it sounds like Drivepool is doing in this case, is assigning different priority classes to the two different drives, which puts it in a situation where it would never read stripe across the two.

  • 0
danielb Newbie

danielb

Posted
  • Author
Posted

Thanks for both of your replies.

Yes the 3TB is slightly slower, since its older, it gets around ~110MB/s.

I was expecting it to work since they say so in this page: http://blog.covecube.com/2013/05/stablebit-drivepool-2-0-0-256-beta-performance-ui/ they even show it working..( http://blog.covecube.com/wp-content/uploads/2013/05/read_duplicated.png )

I didn't really tested this before, since a single HDD would hit the 1Gb NIC max speed, but now that i got a 10Gb NIC, i was hoping to get a bit more performance out of this.

EDIT: Just tested, copying 3 different files, all of them are duplicated 2x. Drivepool seems to insists in using only the 4TB drive?! (see screenshot, i think i showed all relevant stuff)

 

drivepool_problem1.png

  • 0
Umfriend Advanced Member

Umfriend

Posted
Posted
1 hour ago, Jaga said:

I was all set to agree with you Umfriend (actually had it typed in already), until I re-read the docs about read striping.  Large sequential I/O uses block-based read striping, so it should have kicked in for danielb.

 

Yes. But I have never ever been able to get this to work.

For instance, if it would work, then even if you had two HDDs where one would read at 100MB/s and the other at 20MB/s, then a bulk reader should be able to profit from using both.

  • 0
danielb Newbie

danielb

Posted
  • Author
Posted

Well i tried a bunch of random files, and out of nowhere it showed it was read striping, but wasn't able to get it to work again!

This feature seems to be a lot temperamental! It would be great if there was a settings to force it on all the time.

  • 0
Jaga Advanced Member

Jaga

Posted
Posted
2 hours ago, Umfriend said:

Yes. But I have never ever been able to get this to work.

For instance, if it would work, then even if you had two HDDs where one would read at 100MB/s and the other at 20MB/s, then a bulk reader should be able to profit from using both.

Except for the priority classes that Drivepool puts drives into.  i.e. an external USB will always be in a different priority class from an internal SATA drive, no matter what (per the DP docs).  I'm not entirely sure if that gives a benefit when you have super fast external drives (mine are almost as fast as my internal spinners due to their new USB connections), but it's part of the algorithm that Alex put into DP.

 

1 hour ago, danielb said:

Well i tried a bunch of random files, and out of nowhere it showed it was read striping, but wasn't able to get it to work again!

This feature seems to be a lot temperamental! It would be great if there was a settings to force it on all the time.

Which is interesting.  Makes you wonder if the UI is lying to you about block striping in it's UI, or if block striping needs something else to fully kick in on large files.  Might have to wait for @Christopher (Drashna) or @Alex to chime in and let us know.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  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.

Loading...
×
 Share
Go to question listing
×
×
  • Create New...