According to the comments on my other question, it's more than possible that the reason my MD RAID array is performing poorly is because my RAID5 array has 5 data disks. I've tried searching for information on why this is, but haven't found anything, so I'm looking for more information about why this is, and what sort of impact it can have versus having 4 data disks.
asked Mar 3, 2012 at 2:57
-
possible duplicate of Samba running slowly when writing files– MDMarraMar 3, 2012 at 3:01
-
Seriously, this should be addressed in your original question. No need to keep posting dupes with links to the original.– MDMarraMar 3, 2012 at 3:02
-
@MDMarra: Then close the old question. Rewriting the entire question isn't productive either. The issue is nothing to do with Samba, and everything to do with the hardware.– Matthew ScharleyMar 3, 2012 at 3:04
-
1@MDMarra: I disagree; this is a separate question that can standalone, with a reference to a previous question for background if anyone wants more context.– womble ♦Mar 3, 2012 at 3:08
-
2I disagree that the original question has garnered an answer that demonstrates that the problem isn't with Samba. A comment on that question has intimated that the problem may be RAID-related, and now a separate question has been asked about RAID performance issues. Think of it this way -- if the original question was rewritten to be this question, wouldn't it make the comments on that question (and any answers that the original question may have gotten) look like complete nonsense? If so, the question shouldn't be rewritten.– womble ♦Mar 3, 2012 at 3:15
|
Show 3 more comments
2 Answers
I have never heard of any sort of "odd/even" performance impact of a RAID5/6 array, and like you, I can't find anything useful from a quick web search.
There are potential issues with the number of disks and write performance in a RAID5/6 array, but they're related to "more disks == slower writes", because (depending on the implementation) the RAID system may want to read off all the data disks in the stripe in order to recalculate parity (so for a 6-disk RAID5, it would involve 4 reads -- one for each of the unchanged data blocks in the stripe -- and two writes -- one for the changed block, and one for the parity block). A good implementation will instead read the changed data block and the parity block, recalculate the parity, and write to the changed data block and the parity block, meaning two reads and two writes, regardless of the number of disks in the set.
It's the reverse. The issue is when the number of drives is even with RAID 5. With RAID 5, the ideal number of drives is one more than a power of 2, so 5 drives is one of the optimum sizes. This allows the implementation to make both the block size and the stripe size powers of two.
With five drives, the stripe size (amount of user data that must be written to the RAID array as a unit) will be four times the block size (amount of user data that must be written to a drive as a unit). The block size must be multiple of 512 bytes (or 4KB on newer drives), frequently it must be a power of two equal to or greater than the drive's native block size. So with five drives, the stripe size must be 2KB or more (16KB or more on 4KB drives).
As a general rule, the performance boost of adding an additional spinddle will exceed the performance cost of having a sub-optimal drive count. So an array with six drives will still typically outperform an array with five drives. On typical RAID 5 performance graphs, 3 drives and 4 drives will be right near each other, with 4 slightly on top. Then a bit up will be 5 drives and 6 drives right near each other with 6 slightly on top.
answered Mar 3, 2012 at 3:24
-
I'm a bit confused. Isn't the stripe size independent of the number of disks (edit: and user-specifiable)? What do you mean by "block"? Disk sector size, which is 512B or 4KB? Mar 3, 2012 at 3:41
-
No, the stripe size is not independent of the number of disks. If there are five disks, the stripe size must be four times the block size. That's how RAID 5 works and how it tolerates the loss of a disk. (It's
n-1for RAID 5,n-2for RAID 6.) See Wikipedia. I explained what I meant by block size, "amount of user data that must be written to a drive as a unit". It can be any multiple of the disk's native size. Mar 3, 2012 at 3:43 -
2this is nonsense, any layer above the controller treats disks as a continuous range of sectors. there's no need to make the stripe size a power of two. besides, a simple big file transfer would be mostly linearly writing whole stripes. the write amplification factor (two reads and two writes per write command) applies only for small writes. long writes just overwrite the whole stripe, so the factor is just (N+1)/N writes instead of 2N reads+2N writes– JavierMar 3, 2012 at 9:47
-
1The final scheduling is done at the drive level, so neither 2MB nor 2.5 MB multiples matter at all. The individual drives just see requests that are as large as possible, given the original request, the readahead length, and how the request is split across the drives. As long as the original request + readahead is larger than the stripe size, the drives will all get a sufficiently large request for optimal throughput. So if the application asks for 1 MB and the readahead and stripe width are 2.5 MB, then all drives get requests for 512k+.– psusiMar 6, 2012 at 3:53
-
1For partial stripe writes, md has to read the parity block, correct it for the new data, then write the new data plus the new parity block. Neither reading nor writing whole stripes is required, and even if it did, there still would be no reason to keep stripes an even power of two.– psusiMar 6, 2012 at 16:39