Some notes from some ONTAP 8 training I went to:

One of the features in the new version of Data ONTAP 8.0 is the ability to use 64 bit aggregates, prior to this all aggregates were 32 bit.  The main reason to use a 64bit aggregate is to break the 16TB aggregate limit found in 32 aggregates.

ONTAP 7.3 helped with this in that it changed the way the 16TB was calculated, it no longer counted the parity drives in the 16TB which gave you an extra ~20% usable space in your aggregates (actual savings varied based on disk size).  As mentioned before, to expand beyond the 16TB a 64 bit addressing scheme needed to be used, the following shows the limit of either aggregate type:

32 bit aggregates are calculated by 2^32 * 4KB = ~16TB
64 bit aggregates are calculated by 2^64 * 4KB = ~67,108,864 (67 million petabytes)
Note: There are limits to the maximum sizes of 64 bit aggregates which are based on controller model

Those limits are currently:

A few things to note with that are that the maximum file/LUN size is still 16TB and that the maximum volume sizes for dedupe volumes remains the same.

When sizing your system keep in mind that the root aggregate must be 32 bit, it is also important to note that you cannot currently convert a 32 bit aggregate into a 64 bit aggregate (or vice versa).  The next major release of ONTAP 8 will have the ability to convert 32 bit to 64 bit non-disruptively however.

Along the same lines, you cannot perform block level transfers between aggregate types – Volume SnapMirror(VSM) between 32 bit and 64 bit aggregates will not work.  (Qtree SnapMirror(QSM) however will work as it is file based, as will NDMP)

The default type for creating new aggregates is 32 bit, for 64 bit you need to specify a -B 64 if using CLI or select the checkbox if using FilerView.  After upgrading to ONTAP 8.0 7-mode all existing aggregates will remain 32 bit (as mentioned before you cannot non-disruptively convert them yet to 64 bit)

Popularity: 46% [?]