On Sep 9, 2010, at 6:39 AM, Marty Scholes wrote:

> Erik wrote:
>> Actually, your biggest bottleneck will be the IOPS
>> limits of the 
>> drives.  A 7200RPM SATA drive tops out at 100 IOPS.
>> Yup. That's it.
>> So, if you need to do 62.5e6 IOPS, and the rebuild
>> drive can do just 100 
>> IOPS, that means you will finish (best case) in
>> 62.5e4 seconds.  Which 
>> is over 173 hours. Or, about 7.25 WEEKS.
> 
> My OCD is coming out and I will split that hair with you.  173 hours is just 
> over a week.
> 
> This is a fascinating and timely discussion.  My personal (biased and 
> unhindered by facts) preference is wide stripes RAIDZ3.  Ned is right that I 
> kept reading that RAIDZx should not exceed _ devices and couldn't find real 
> numbers behind those conclusions.

There isn't a real number.  We know that a 46-disk raidz stripe is a recipe for 
unhappiness (because people actually tried that when the thumper was released)
And we know that a 2-disk raidz1 is kinda like mirroring -- a hard sell.  So we 
had
to find a number that was between the two, somewhere in the realm of reasonable.

> Discussions in this thread have opened my eyes a little and I am in the 
> middle of deploying a second 22 disk fibre array on home server, so I have 
> been struggling with the best way to allocate pools.  

Simple, mirror it and be happy :-).

> Up until reading this thread, the biggest downside to wide stripes, that I 
> was aware of, has been low iops.  And let's be clear: while on paper the iops 
> of a wide stripe is the same as a single disk, it actually is worse.  In 
> truth, the service time for any request on wide stripe is the service time of 
> the SLOWEST disk for that request.  The slowest disk may vary from request to 
> request, but will always delay the entire stripe operation.

Yes, but this is not a problem for async writes, so it will depend on the 
workload.

> Since all of the 44 spindles are 15K disks, I am about to convince myself to 
> go with two pools of wide stripes and keep several spindles for L2ARC and 
> SLOG.  The thinking is that other background operations (scrub and resilver) 
> can take place with little impact to application performance, since those 
> will be using L2ARC and SLOG.
> 
> Of course, I could be wrong on any of the above.

If you get it wrong, you can reconfigure most things on the fly.  Except you 
can't
add columns to a raidz or shrink. A good strategy is to start with what you need
and add disks as capacity requires.  Oh, and by the way, the easiest way to do
that is with mirrors :-)  But if you insist on raidz, then consider something 
like 
6-way or 8-way sets because that is the typical denominator for most hardware
trays today.
 -- richard

-- 
OpenStorage Summit, October 25-27, Palo Alto, CA
http://nexenta-summit2010.eventbrite.com
ZFS and performance consulting
http://www.RichardElling.com












_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss

Reply via email to