ONTAP Discussions

different number of disk in Raid Groups of the aggregate


I have 3 shelves with 72 disk for my 8020 (Ontap8.3.1P1- cluster mode).

I want to get as much as usable size for the aggregate.

Therefore, this is what I plan to do.

One root aggregate for controller 1 - 3 disk with 2 spare.

One root aggregate for controll 2 - 3 disk with 2 spare.

Then I only have 62 disk left.

Therefore, I have given all 62 disks to be owned by controller1 for an aggregate.

Config an aggregate with three raid groups.

It is going to be rg0-20, rg1-21, and rg2-21.

Here is my question.


  1. Can I create three raid groups with the different number of disk in the aggregate?
  2. If #1 is yes, how to config it?  Should I cretae
  • rg0 size 20, rg1-size 21, rg2 size 21 or
  • rg0, rg1, rg2 are size 21 but only given 20 disk to rg0.

3. What order I sohuld config for the raid groups - rg0-20, rg1-21, rg2-21 or rg0-21, rg1-21, rg2-20?





Yes, you can do it. By default NetApp will leave last group incomplete, so simply set desired rg size when creating aggregate. It does not really matter in which order raid groups will be.


So you are talking about that I suhold create three 21 disk size raid groups and given 20 disk to one of the reaid group.

Am I right?


I do not say what you should do, it is up to you to decide; but you could do it, yes.


Good discussion.  You've covered the can you and the should you.   How about a what if?  Give the idle node 1 spare.  Make all 3 raid groups 21 wide.  


Its a little wide for my tastes, I tend to gravitate back to 16 because of the nice 2shelf=3rg cadence.  But it would squeeze every little bit of capacity out of that inventory.




If this post resolved your issue, help others by selecting ACCEPT AS SOLUTION or adding a KUDO.


John -


While you could do what you are proposing, I suggest that you don't.  Reasons:


1.  There is one RAID group size per aggregate.  You can designate as you add disks which raid group you add into.  In your design you will purposely have one raid group short a disk.  In the future, if you expand the aggregate after a storage expansion, there is a small chance that you will forget about the one raid group and a disk will go in there.  That one single disk would prove to be a significant peformance limiter.  Of course there is a valid argument to make that you should never expand aggregates ever (just create new ones as you expand storage) which is also a performance driver.


2.  You are looking at a raid group size of 21.  That implies that you have SAS-class disks where the max raid group size is 28.  SATA-class disks max out with a raid group size of 20.  Assuming SAS class disks, you obviously have a desire for performance.  Having evenly distributed raid groups gives your system the best overall average performance because there all the parts perform evenly.  One can argue whether a raid group with 20 disks makes that much difference to one with 21, but I've evaluated existing systems in the past where performance was affected by just such a design - a critical read mostly volume ended up heavily on a smaller raid group within an aggregate and performance was clearly affected.  Unless you have very tight requirements you probably wouldn't see this affect in your case, but it does exist.  This edge case is why the best practice for raid groups is to keep them evenly and fully filled.


If you agree with points, I suggest using a raid group size of 20 and that leaves you with two additional spares in total.  And of course if your disks are SATA class, rg size 20 is as high as you can go.


If you are going to leave one RAID group short a disk, don't worry about the raid group creation order.  Just create the aggregate with a raid group size of 21, then add 62 disks.  My preference is always to let the system do disk selection and layout, and you don't have enough to allow for a whole shelf failure, so there is no benefit to laying out the disks manually.  The last raid group in the aggregate will just be short one disk.



I hope this helps you.


Bob Greenwald

Lead Storage Engineer

Huron Legal | Huron Consulting Group

NCDA, NCIE-SAN Clustered, Data Protection


Kudos and accepted solutions are always appreciated.