I wanted to take a few minutes (famous last words before this becomes essay length) about Temperature Sensitive Storage Efficiency (TSSE) available on NetApp ONTAP platforms. It’s a fairly straightforward concept, but enhancements and the release of NetApp’s new AFF C line have injected a bit of confusion. Hopefully this helps clear things up, or at least points you in the right direction.
What is TSSE?
A core component of ONTAP is a series of built in storage efficiencies, including deduplication, compression, and compaction. Through in-line processes data that is written to an AFF ONTAP platform is reduced before being written to disk (FAS platforms don’t have inline efficiencies enabled). In addition there are various secondary operations that come in and finesse the data afterward to eek out more efficiency. TSSE is one of those.
TSSE is specifically a function of the compression methodologies. Typically incoming data is compressed into 8K compression groups before being written to disk. The “temperature sensitive” part of TSSE means that ONTAP will keep track of the compressed groups and, if they’re marked as cold, will compress them further into 32K groups.
Hot/cold is a question of when was the last time those initial 8K groups were accessed – by default that threshold is 14 days. After a chunk has not been accessed for 14 days, it’s marked as cold. As ONTAP runs secondary efficiency processes it’ll grab a bunch of those cold groups and compress them down into a 32K group.
Compression, by its nature, imparts workload on a CPU to compress/decompress. In addition there’s also the activity required to read/wire/perform disk cleanup. By focusing on cold data ONTAP can reduce space on disk in a deprioritized manner. All these activities that use resources in a way that doesn’t impact inbound/outbound IO.
The only catch… well catch isn’t the right word… the only consideration is there will be a potential for higher latencies when pulling data that’s been through the TSSE process. I’d say the majority of environments will not notice anything, but it’s worth addressing if your application goes through hot/cold cycles but has a consistent need for low latency.
How you address this depends on what version of ONTAP you’re running, leading me into the next section…
TSSE on ONTAP 9.8 and 9.9.1
TSSE was introduced with ONTAP 9.8. Systems running ONTAP 9.8 and 9.9.1 get TSSE enabled automatically for any newly created volumes. Any volumes that existed prior continue to use basic 8K compression.
Key notes here:
- You CANNOT enable TSSE on any volumes that existed prior.
- You CAN disable TSSE on any newly created volumes.
- You CAN replicate TSSE enabled volumes back to 9.7 (or prior as supported by SnapMirror). In this scenario the destination just keeps the 32K groups until acted upon.
TSSE on ONTAP 9.10.1 and later
Somewhere between those prior two releases someone said, “Hey, why not make this configurable?” and everyone celebrated like you could have both hard and soft tacos for dinner. Thus a configurable flag was created so users could create volumes with either basic 8K compression and TSSE with 32K groups.
Volumes without TSSE enabled are operating in “default mode.” Volumes with TSSE enabled are operating in “efficient mode.” Default, as the same suggested, is the mode in which new volumes are created… by default. You can enable TSSE at time of creation, or after the fact, by using the -storage_efficiency_mode flag.
Part of this change also includes the introduction of a more intensive compression algorithm (ZSTD) for TSSE. The net of this means greater savings through compression, at the risk of higher performance impact when reading from those compressed groups.
Disabling TSSE
I’m not going to get into the how, that’s a better conversation to have with your NetApp representative or support (the KB broadly mentions 9.8 and later, but it looks like there are different commands in 9.12…). What I do want to mention is that disabling TSSE, from what I’ve told, involves disabling all storage efficiencies on a volume. This inflates the volume on disk to its full capacity before you re-enable efficiencies to shrink it back down. Make sure you have enough free space up front.
Can you do any of this in System Manager?
If you have to ask… (the answer is no)
TSSE and the C-AFF Series
The new capacity based AFF series from NetApp (AFF C series) is a bit of a departure from above as TSSE is enabled by default for all newly created volumes. This is inline with the AFF C use case, high capacity, high density, better-than-FAS-but-slower-than-AFF performance targets.
The good news is volumes that enter AFF C externally, either through a vol move or as a SnapMiror target, do not get TSSE enabled. This means you can cleanly move volume to and fro a AFF C without having to worry about triggering TSSE and bringing back any sort of performance penalty.
One thing to watch out for, in mixed clusters, make sure you create the volume in the right place to ensure the proper TSSE flags are triggered upon creation.
In Conclusion
So, if you think any of this was confusing, just wait till you start looking at the nibbly tiddly bits that impact the compression algorithms, how and when background processes run, and various enhancements to the TSSE stack across each ONTAP release. Oh, and don’t get me started on trying to decipher what storage efficiencies come from where.
But really, for most customers and environments, this doesn’t really matter. Getting into the weeds is fun, but this is really a KISS scenario. If you’re targeting the maximum storage efficiencies from your ONTAP system, where performance is a secondary consideration, then TSSE is the way to go. If not, leave TSSE off.
Additional Reading
- NetApp’s TSSE Documentation – Note the top level of this article as an entry way into all the storage efficiency toggles
- KB article on how to disable TSSE
Version History:
- June 15th, 2023 – Initial posting
- June 22th, 2023 – Some rudimentary proofreading