3

Scenario: we're running a large (3TB total in cluster) Solr installation in EC2. I'm only concerned about disk performance on the read side of things. We suspect that we are limited by disk I/O and specifically get problems when an EBS volume decides to get flaky and slow down.

I am considering trying out RAID 1. From what I understand Linux software RAID will split the reads between disks, but I'm not sure how smart it is. If one of the disks in a RAID 1 pair gets backed up on reads, will it send more reads to the other disk? If a read has been pending too long, will it reschedule that read to the other disk?

I can't think of any way to test this behavior. I'd be happy to look through the code, but I'm not even sure if this would be handled by the I/O scheduler or if it's part of the raid drivers. I can't find any documentation that goes into any more depth than the software RAID HowTo.

Lucas Kauffman
  • 16,818
  • 9
  • 57
  • 92
Kevin Peterson
  • 205
  • 1
  • 6

1 Answers1

2

The read balancing is handled in the md drivers in the kernel; drivers/md/raid1.c

It's not super clever. It tries to minimize seeks and that's about it. I'm not sure if any of the RAID implementations are as clever as you want...

Do you have enough memory in your systems? If it's really read-heavy, caching should help a bit.

James
  • 7,553
  • 2
  • 24
  • 33
  • 1
    I've gone through raid1.c, and I think the default behaviour is perfect for highly concurrent random reads. The only 'problem' is that it doesn't speed up sequential transfers by a single thread. – Seun Osewa May 05 '11 at 22:35