nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

AFF C190 Compression Poor Performance

YeremiaSionC

Hi All,

We have an issue in our customer project, we are migrating data from DC Site (AFF C190) to DRC Site (AFF C190) using Commvault, both NetApp AFF C190 version ONTAP 9.8P3. data migrated from source to destination is 6TB and our capacity is full in the DRC then i check in the storage saving. The issue is why compression performance is very poor, we only got 1.00:1 ratio also same with Deduplication just giving 1.00:1 ratio. Inline Compression, Inline Dedupe, Compression, Dedupe, Compaction are already enabled.

Here is some information i can provides:

Find more posts tagged with

AFF

Accepted answers

Ontapforrum

I think there is a major change in Ontap 9.8 compression process, as it differentiates data into cold and hot classification. Hot data is compressed inline using 8K compression groups, and the old data is then compressed again in the background using a more aggressive 32K compression group. These changes mean better performance for hot data and better data reduction ratios for all data.

I believe in your case - the data that has come in (via migration) is considered 'hot' so its less aggressive and I believe over a time (depending upon the default cooling period), your aggr efficiency will improve as it will have more 'colder' blocks to compress using 32k compression set/group.

This kb is worth a read, though it's NOT the cause for your issue. It's just a information guide for changes in Ontap 9.8 for adaptive inline compression.
https://kb.netapp.com/Advice_and_Troubleshooting/Data_Storage_Software/ONTAP_OS/No_compression_savings_in_ONTAP_9.8P1

All comments

Ontapforrum

YeremiaSionC

Hi,

Thanks for the replies!

Anyway is there a way to change / modify the TSSE Cooling periods to make it more shorter?

CHRISMAKI

How was Commvault used to migrate the data, was it orchestrating Snapmirror in the background, or was Commvault the actual data mover. Is it possible that Commvault either compressed or worse, encrypted the data, making it non-compressible to ONTAP?

The instructions for running post-process sooner are in that KB pointed out above. Run a 0-day cold data scan:

volume efficiency inactive-data-compression start -vserver <vserver> -volume <volume> -inactive-days 0

YeremiaSionC

Its using Commvault data mover, since the Commvault used was software version it doesn't provide compression from Commvault itself. but the issue already solved.