30 LUN's or 18 ? 3 RG's per DAE and 6 LUN's per RG makes 3 x 6 = 18 LUN's.

My gut feeling says SATA is not the way to go here since SATA can be ok with sequential I/O and far less with random I/O. Best practice is to create as few LUN's as possible on SATA RG's so as little random I/O will take place on each RG.

Do you see any difference in the load on all 3 RG's ? for example: if RG1 is hit much harder than RG's 2 and 3, I can imagine that the meta heads are all on RG1 and hit the hardest, where components 2 and 3 of each meta is doing far less, so RG1 is getting all the load where RG2 and 3 are "sleeping" since there's less data there.

Personally I would not have choosen SATA for production. SATA is ok for very light apps and it's very good for backup since that's very sequential.

Can you clarify one thing in this scenario?

I'm kind of assuming you are using Concatenated Metas as opposed to striped, but I'd like to be sure. From what I can see of your configuration you would either be wasting space on the two larger RGs or you are losing the advantage of spreading the IO load by using concatenated Metas. Either way is not really an optimal use of resources. To get a properly balanced load with the most effective use of resources, you would want:

- all the RGs to be the same size
- Metas should be striped.
- the "leading edge" of the Metas should be rotated through the RGs
- For the workload you are talking about I agree with RRR that you should probably be using FC drives instead of SATA
- In and absolutely ideal environment you would probably mix up LUNs from different RGs on different DAEs to make up your Metas to balance any potential load across backed components. It sounds like this may really not be as much of a concern with your workload though

I automatically assumed concattenated meta's because of RG3, which is smaller than the other 2. The rotating head is also an important point with concattenated meta's (I totally forgot to mention this).

I did too, at first look, but if history has taught me anything it is that assumptions can undo what would otherwise be a perfectly good conclusion when troubleshooting I spent too long on the Service Desk at our company to assume people did things the way that makes sense based on lot's of experience unless I know that they are experienced and can trust that they probably did the right thing.

I'm not trying to offend anyone with that statement, just being brutally honest about my personal experience with customers

It's good that none of us assumed I asked the question of the person that install the array.. all metaluns are striped.

yes 18 is the magic number

Hi Allen,

I had my eyes shut when i went into the RG properties.. lass some good news. There is free space at the end of a few RGs (not all). They are expecting to add more meta luns.

anyway cheer for all of your help.

JL

Wow... even though I asked the question I wasn't really expecting that answer. So right now You are possibly losing up to 266GB per DAE to this. For every four DAEs that adds up to over 1 TB.

So I guess the next question is... were all the Base LUNs on the 5 drive RGs built to use the full capacity of the RGs? Or were they built to the maximum size you could build the base LUNs on the 4 drive RG? For the former, the wasted space is "hidden" by the MetaLUN configuration. If the Latter the wasted space is still available for allocation, just not the same as the existing configuration.

BTW - Do I get bonus points for calling that one ???