On Wednesday January 18, francois.barre@xxxxxxxxx wrote: > 2006/1/18, Mario 'BitKoenig' Holbe <Mario.Holbe@xxxxxxxxxxxxx>: > > Mario 'BitKoenig' Holbe <Mario.Holbe@xxxxxxxxxxxxx> wrote: > > > scheduled read-requests. Would it probably make sense to split one > > > single read over all mirrors that are currently idle? > > > > A I got it from the other thread - seek times :) > > Perhaps using some big (virtual) chunk size could do the trick? What > > about using chunks that big that seeking is faster than data-transfer... > > assuming a data rate of 50MB/s and 9ms average seek time would result in > > at least 500kB chunks, 14ms average seek time would result in at least > > 750kB chunks. > > However, since the blocks being read are most likely somewhat close > > together, it's not a typical average seek, so probably smaller chunks > > would also be possible. > > > > > > regards > > Mario > > Stop me if I'm wrong, but this is called... huge readahead. Instead of > reading 32k on drive0 then 32k on drive1, you read continuous 512k > from drive0 (16*32k) and 512k from drive1, resulting in a 1M read. > Maybe for a single 4k page... > > So my additionnal question to this would be : how well does md fit > with linux's/fs readahead policies ? The read balancing in raid1 is clunky at best. I've often thought "there must be a better way". I've never thought what the better way might be (though I haven't tried very hard). If anyone would like to experiment with the read-balancing code, suggest and test changes, it would be most welcome. NeilBrown - To unsubscribe from this list: send the line "unsubscribe linux-raid" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
