Re: setting up raid10 with more than 4 drives

On 5/31/07, mark@mark.mielke.cc <mark@mark.mielke.cc> wrote:
> On Thu, May 31, 2007 at 01:28:58AM +0530, Rajesh Kumar Mallah wrote:
> > i am still not clear what is the best way of throwing in more
> > disks into the system.
> > does more stripes means more performance (mostly) ?
> > also is there any thumb rule about best stripe size ? (8k,16k,32k...)
>
> It isn't that simple. RAID1 should theoretically give you the best read
> performance. If all you care about is read, then "best performance" would
> be to add more mirrors to your array.
>
> For write performance, RAID0 is the best. I think this is what you mean
> by "more stripes".
>
> This is where RAID 1+0/0+1 come in. To reconcile the above. Your question
> seems to be: I have a RAID 1+0/0+1 system. Should I add disks onto the 0
> part of the array? Or the 1 part of the array?

> My conclusion to you would be: Both, unless you are certain that you load
> is scaled heavily towards read, in which case the 1, or if scaled heavily
> towards write, then 0.

thanks . this answers to my query. all the time i was thinking of 1+0
only failing to observe the 0+1 part in it.

>
> Then comes the other factors. Do you want redundancy? Then you want 1.
> Do you want capacity? Then you want 0.

Ok.

>
> There is no single answer for most people.
>
> For me, stripe size is the last decision to make, and may be heavily
> sensitive to load patterns. This suggests a trial and error / benchmarking
> requirement to determine the optimal stripe size for your use.

thanks.
mallah.

>
> Cheers,
> mark
>
> --
> mark@mielke.cc / markm@ncf.ca / markm@nortel.com     __________________________
> .  .  _  ._  . .   .__    .  . ._. .__ .   . . .__  | Neighbourhood Coder
> |\/| |_| |_| |/    |_     |\/|  |  |_  |   |/  |_   |
> |  | | | | \ | \   |__ .  |  | .|. |__ |__ | \ |__  | Ottawa, Ontario, Canada
>
>   One ring to rule them all, one ring to find them, one ring to bring them all
>                        and in the darkness bind them...
>
>                            http://mark.mielke.cc/
>
>