The standard way to setup a RAID 1 under Linux is to use two disks of the same size. The write performance is almost as good as with a single disk drive. The read performance can be up to twice the speed of a single disk.

For additional redundancy, we want to add another disk as a hot spare to the system.

In the past the rebuild of RAID 1 and RAID 5 setups with disk sizes of 1-3TB did sometimes cause problems, because the "still living" disks are heavily stressed for the rebuild, and then also might fail...

We have now read that with Linux we can also make a RAID 1 with 3 identical disks. That way the writes go directly to all 3 disks, and when a disk fails there is no need for a instant rebuild on the hot spare.

So far things are clear for us.

But what about performance?

  • Will the writes be slower, because data has to be written to 3 disks at the same time?
  • Will the reads be (up to) 3x faster, since it can read from 3 different disks?

Other things to consider in such a setup?

1 Answer 1


There's nothing wrong with RAID 1 over three disks.

Writing will be as fast as the slowest disk allows.

All three disks will be utilized for reading, if you have enough processes doing reading. A single read operation is always served by a single disk only, so it depends on your application(s) whether it can make use of several disks worth of reading performance.

As usual, the best way to answer performance questions is to benchmark it yourself.

because the "still living" disks are heavily stressed for the rebuild, and then also might fail

Test your disks regularly. Bad sectors can go undetected for extended periods of time otherwise. Until you have to rebuild because your other disk also broke, as the rebuild also happens to be a complete read test for the remaining disks...

  • Regarding disk failure, as same disks of same models have same MTBF, when a disk is replaced, the disks that remains are close to the failure and the rebuild is a real "stress test" for that remaining disks. So best is to replace disks regularly if you can afford it.
    – Emmanuel
    Dec 6, 2013 at 11:05
  • A disk may fail at any time, that's why you have backups. But I still think many people are seeing old failures during resyncs, as few people do proper monitoring. That makes it look like the disks failed at the same time, when they really didn't. I never understood why a rebuild is seen as a "stress test"; a busy box will stress its disks with random I/O 24/7, the rebuild on the other hand is a linear read, apart from being idle that's the least stressful operation possible. And mdadm heavily tunes down the speeds when the box has other things to do. Dec 6, 2013 at 13:44
  • In real world applications, the server is just busy with normal IO and in addition to this the rebuild is putting additional load on the disks. At least we have the servers online when doing a disk replacement, and then the disks jump even more from the linear rebuild to the random IO... Dec 10, 2013 at 9:19
  • I still don't think so, but I'm tired of the argument. :) Dec 10, 2013 at 12:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .