Not in my experience, but certainly your mileage may vary.
---
After thousands of perfstats, still looking for that exampl.e
However, if you *mix* rg sizes within the aggr, you are causing the filer
to do more work.
---
Where is the more work at? Yes..if this causes you to have -1- extra raid group on the box, there is minimally measurable overhead to manage additional raid groups..no surprise there.
> "The other problem is that moving forward if you have optimized your writes
> for the 16 disk rg stripe size, some rgs are going to be optimized and
> some aren't, which could conceivably affect performance."
> ---
> Im trying to understand this statement as well. Writes are optimized for
> the full stripe of the aggregate. RG size, again, has nothing to do with
> it as a "stripe".
>
> Raid groups are zones of data protection.
Yeas, rgs are zones of data protection (really they are spindle protection
in a NetApp -- basically the same thing, but again, theory vs. practice).
---
I think we can agree that data = spindles and not construct a difference of opinion over it. Thats what I meant. :)
However, as Davin pointed out, there are different stripes in play here.
RAID-4 and RAID-DP, by their nature, have stripes. They have to in order
to calculate the parity data. So each rg has a stripe width.
---
Yes. But the application cant see it.
An aggregate is, at the most basic level, just raid-0. We usually use the
term "wide stripe" to talk about a stripe of stripes. We've created
protection at the raid group level, and now we're gluing those raid groups
together to take advantage of better i/o in a large number of spindles.
That's why I create as large an aggregate as I can and let the filer
figure out where the hot spots are. It also minimizes wasted space.
---
Yes.
Anyway, that wide stripe works best when all of the calculations are the
same. However, if you use different-sized raid groups within the
aggregate, the filer has to do more work.
---
I'll accept that. But it doesnt manifest itself meaningfully in the USER space. The CP is outside the view of the user, the read IO has no stripe construction overhead..so as Ive been saying...the BP is NOT to do it, but in the vast majority of instances where people have done this by mistake/etc, its not a huge problem.
The aggregate size by spindle and type is the performance envelope.
What goes on in a serialized domain after the client has had the write ACK'd, isnt felt by the user..short of getting to the point of overrunning the controller with write IO itself...then we can talk the shavings of performance left on the table. IMHO, RG count on a system has the same overhead, which would fire up the debate over small/mid/huge size RG's to recapture the overhead in stripe calculation(s). Which IMHO, is more a business decision over risk/reward.
It may be minimal work, and the
filer can handle it, but these things start to add up if you're looking
for performance. It may be that a 4 disk rg performs only a few percent
slower than a 16 disk rg. Now combine that with a 12 disk and 6 disk rg
and add them all to an aggregate where the filer has to do a few percent
more calculations to do the wide striping properly...
Man, Randall, you sure ask good questions. :)
---
And at this level...were in violent agreement. :) :)
Ive never chastised (lightly or otherwise) a customer with RG's that dont balance out perfectly...we discuss it, but if a disk purchase is not in store to solve a perf issue Im consulting over, I dont suggest that capital and effort be taken to resolve it at that time. It's rare, IMHO, to see that overhead manifest itself in the user space. You have to exhaust the CP engine to do it, then even so, you're likely still left with a sizing challenge to resolve. (Legacy HW servicing new user loads, etc)
Later on..a few disk adds and a few injections of reallocate to the patient are in good order.