Re: Why are reads not balanced across my RAID-1?
From: Roberto Spadim <hidden>
Date: 2014-01-24 18:22:56
Hi guys, i done some tests some time ago, and what i can tell is Raid1 use the nearest disk algorithm to select what disk will execute reads (read balance) i think it's very good, but don't consider diferent disk speed (access time and continous read), but it do a very good job i don't know there's space to improvement here, i got 1% of speed up doing a mix of disk speed (7.2k rpm 5k rpm and 15k rpm and a ssd) and changing the read balance algorithm i think it's solid 1% of speed up, but confuse to config parameters, parameters are based with access time (head time to move from position 0 to end of disk, or 0 for ssd) and continous read (based on mb/second in a continous read, or based on rpm and track size) the best i got is: if you want raid1 you will run a system like databases, or multi thread systems, each thread operating a disk if have a system with continous read/write (dvr, stream, etc) raid10 far is the best maybe more tunes you can do with align, read ahead, and others filesystem options/parameters and cache, a raid card with flash backup or battery is nice too good luck 2014/1/24 [off-list ref]
On Fri, Jan 24, 2014 at 08:56:02AM -0600, Matt Garman wrote:quoted
On Fri, Jan 24, 2014 at 6:04 AM, [off-list ref] wrote:quoted
The reading is not balanced because it does not make sense to do balanced reads for sequential reading. In RAID-1 the disk sectors are consequitive. So if you would read one sector from one disk, and the following sector from the other disk, then the next read from disk 1 would need to skip a full resolvation of the disk, which may cost something like 8 ms. So better read contigously from the same disk, and hope for some other IO request that can use disk 2.Does that rationale hold for SSDs?No, this is not relevant for SSDs as access time is almost zero. best regards keld -- To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
-- Roberto Spadim