ONTAP Discussions

Compression on primary storage flexvol, supported or not?

dejanliuit
3,198 Views

We were to upgrade to Ontap 8.0.1 to gain access to the compression feature to compress data on flexvols on our primary data storage.

But the consultant (also netapp releller) calims that compression is not supported on primary storage without a PWR.

If so, we would rather wait for later release where it is supported and at the same time hopefully to avoid the (unexisting) 32-64 bit WALF conversion as it has to be done today.

This would be quite opposite to what I read out from the DOC-8170 where it claims that it is supported on primary, secondary and archival storage.flexvols

Can anyone confirm or dispute their claim?

1 ACCEPTED SOLUTION

scottgelb
3,198 Views

It does require a Policy Variance Request (PVR) just to make sure the system has enough CPU to enable compression and the data type will benefit from compression.  We have had no issue getting PVRs completed on primary storage FlexVols and NetApp responds quickly (thanks Sandra!) to the requests.  They even give a temporary key until the permanent (and free) key is built.  But is an extra couple of steps to get it working.  You also need to make sure you are on a P release of 8.0.1 (p5 is now out) that has some bug fixes.  There was a bug that caused a core dump that is fixed and there is still a BURT pending on ndmp/dump backups.  If you do ndmp or dump of the FlexVol then do not enable compression (unless that burt is fixed - but I don't think it is yet).

You make a very good point on 64-bit... upgrading from 7.3 to 8.0.1 alone won't allow compression since all existing flexvols will be 32-bit aggregtes. So you need to create new 64-bit aggregates to use compression.  8.1 which will convert 32 to 64 and also have compression without a PVR should increase the adoption rate.

View solution in original post

4 REPLIES 4

scottgelb
3,199 Views

It does require a Policy Variance Request (PVR) just to make sure the system has enough CPU to enable compression and the data type will benefit from compression.  We have had no issue getting PVRs completed on primary storage FlexVols and NetApp responds quickly (thanks Sandra!) to the requests.  They even give a temporary key until the permanent (and free) key is built.  But is an extra couple of steps to get it working.  You also need to make sure you are on a P release of 8.0.1 (p5 is now out) that has some bug fixes.  There was a bug that caused a core dump that is fixed and there is still a BURT pending on ndmp/dump backups.  If you do ndmp or dump of the FlexVol then do not enable compression (unless that burt is fixed - but I don't think it is yet).

You make a very good point on 64-bit... upgrading from 7.3 to 8.0.1 alone won't allow compression since all existing flexvols will be 32-bit aggregtes. So you need to create new 64-bit aggregates to use compression.  8.1 which will convert 32 to 64 and also have compression without a PVR should increase the adoption rate.

dejanliuit
3,198 Views

Thanks for explaining the reason behind the PVR.

Is there any thumb-rule when the CPU is enough?

Ie our Filers CPU run at 20-40% during normal service hours and only during dedupe its up in 80-99% busy and we have data we think would gain a lot from compression (homedirectories with a lot of static data).

The NDMP BURT is a showstopper as we do backups with TivoliStorageManager with NDMP.

We will have to wait for a little while more to proceed with the project.

Do you have any downloadable tool that we could use to check the vol/qtree/dir data compressability ourselfs?

Or do we have to go thru the support organization with an official PVR?

I would like to know for sure if compression is something we would gain from before starting the whole process of getting management clearance, finding a service window etc.

scottgelb
3,198 Views

Your VAR or NetApp SE can run the space savings estimator to estimate both the compress and dedup rates.

The cpu will be looked at for the pvr to see if it is a fit by the netapp team that approves the pvr. The burt for ndmp/dump is 485411.

Typos Sent on Blackberry Wireless

dejanliuit
3,198 Views

Ontap 8.0.2 is out, yet the BURT doesn't indicate that the bug is fixed. Quite unfortunate for something that feels like a serious bug.

But on the bright side, if I understand the BURT correctly it doesn't affect systems with a three way NDMP backup (as in our case) so I will doublecheck with our support if it is OK to go ahead anyway.

Public