Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

share|improve this question
possible duplicate of Samba running slowly when writing files –  MDMarra Mar 3 '12 at 3:01
Seriously, this should be addressed in your original question. No need to keep posting dupes with links to the original. –  MDMarra Mar 3 '12 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 Scharley Mar 3 '12 at 3:04
@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 '12 at 3:08
I 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 '12 at 3:15

2 Answers 2

up vote 10 down vote accepted

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.

share|improve this answer

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.

share|improve this answer
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? –  Mark Wagner Mar 3 '12 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-1 for RAID 5, n-2 for 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. –  David Schwartz Mar 3 '12 at 3:43
You are confusing the block size with the stripe size. You can specify the block size, and it's independent of the number of disks (but must be a multiple of the drive's native block size). But then the stripe size will be, for RAID 5, the block size times the number of disks minus one. That's how RAID 5 works. –  David Schwartz Mar 3 '12 at 3:48
Blocks have nothing to do with it. Typical stripe factors are 64-512KB. Recent versions of mdadm default to 512KB so a 4 disk array will have a stripe size of 2 MB, and a 5 disk will be 2.5 MB. Whether it is 2 or 2.5 MB makes no difference; there is no reason it should be an even power of two. –  psusi Mar 3 '12 at 5:36
How can a 4 disk RAID 5 array have a stripe size of 2MB? That would be 2/3MB per disk. If it writes, say 512KB per disk, that's 512KB*3 of data and 512KB of parity for each stripe. –  David Schwartz Mar 3 '12 at 7:29

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.