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)

Originally posted at: http://mtellin.com/2010/01/06/netapp-64-bit-aggregates-in-ontap-8-0/

Obviously you need to be aware that enabling compression will add additional load onto your system but keep in mind you can use FlexShare to set lower priority to system level (e.g. SnapMirror) operations.  Another thing to keep in mind is that FlexShare is assigned per volume, so it doesn’t have to assign ALL of your SnapMirror transfers a low priority.

Enabling compression is as easy as modifying the /etc/snapmirror.conf file, you can enable compression on existing SnapMirror relationships.  The changes you need to make are as follows:

At the top of snapmirror.conf you need to establish a connection name and assign the source and destination filers to it.  For my example this will be:

sm1=multi(940-1,940-2)

<connection name>=multi(<sourcefiler>,<destinationfiler>)

Now you need to modify the existing line for the SnapMirror schedule, my example looks like this:

sm1:test_vol 940-2:test_vol_recv compression=enable – 10 * * *

Example:

For my example I was setting this up on a FAS940, I ran ‘sysstat –s 1’ before running the snapmirror and it averaged about 1% CPU usage

Source NetApp:

Destination NetApp:

After kicking off the initial snapmirror transfer I re-ran the same command and it returned an average CPU usage of 72% on the destination and 100% on the source.

Source NetApp:

Destination NetApp:

So again if you have a busy system, you will need to decide if the decreased WAN traffic outweighs the added load on your system.  I kicked off a ’snapmirror initialize’ and then monitored the transfer with ’snapmirror status -l’ and saw that I was getting a steady 8.0:1 compression ratio on my transfer.

Originally posted at http://mtellin.com/2009/11/23/using-compression-with-snapmirror-transfers-in-ontap-7-3-2/