> Anyone who would mix drives of such disparate spindle speeds within the same > array is not concerned with performance. Anyone who has read enough to create > their first array knows better than to do this. i don't think that... let's talk about internet link? we can have two internet links (1 radio, 1 adsl or another), with linux i can load balance based on network band use, round robin, and many others ideas it's same for raid1, except, write speed = slowest write speed, for read we can get highers speed (with raid1 we can have same speed than raid0, or, we should...) > Why waste effort to optimize such a horrible design decision? a horrible design decision: two 1TB ssd with 1,5GB/s and two 1TB ssd with 2,0GB/s (can be from texas... or ocz...) using raid1, it's a horrible design? or... for hard disks two 1tb sas with 300MB/s and two 1tb sas with 250MB/s (i never get more speed than 300mb/s with hard disks) is it a horrible design? > This is just silly. no, it's a option, we could use round robin, near head, and another read balance algorithms, the closest to read world the faster we get now it's true for raid1: write speed is poor (that's why we use raid10) but read can be as fast as raid0 .... even faster since all disks have the same information... what we need is a good read balance algorithm (i think for a non balanced array, a time based is the best option...) 2011/2/3 Stan Hoeppner <stan@xxxxxxxxxxxxxxxxx>: > Roberto Spadim put forth on 2/2/2011 2:28 PM: > >> i don´t think, since head, is just for hard disk (rotational) not for >> solid state disks, let´s not talk about ssd, just hard disk? a raid >> with 5000rpm and 10000rpm disk, we will have better i/o read with > > Anyone who would mix drives of such disparate spindle speeds within the same > array is not concerned with performance. Anyone who has read enough to create > their first array knows better than to do this. > > Why waste effort to optimize such a horrible design decision? > >> 10000rpm ? we don´t know the model of i/o for that device, but >> probally will be faster, but when it´s busy we could use 5000rpm... >> that´s the point, just closest head don´t help, we need know what´s >> the queue (list of i/o being processed) and the time to read the >> current i/o > > This is just silly. > > -- > Stan > -- > 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 > -- Roberto Spadim Spadim Technology / SPAEmpresarial -- 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
