If you enable compression on a performance policy, what affect does it have on the performance of the volume?
Don't want to turn this into a sales pitch about the product - but the CASL file system is built to work with compressed, variable block sizes - meaning the file system is structured around the idea of using compression on your primary data. We use LZ4 software based compression which happens inline on incoming data into your storage processors (so it's not a post-process or scheduled task).
Therefore there is no performance detriment for enabling the compression on a Nimble performance policy. In fact, the majority of policies have it set to enabled by default.
Now, compression ratios will vary from application to application, but regardless of whether you get 1.1x (RAW images, perhaps) or 3x (Oracle DBs) - you don't see any hit on your performance of that volume.
Hope that answers your question!
So what situation would you turn it off if it does not affect performance.
If the dataset being written to the array isn't compression-friendly. Saves CPU cycles (the array's not trying to compress uncompressible stuff) which can be used for other things.
I've had a look at using deduplication filesystems on Windows Server 2012 residing on a Nimble box, and achieved 1.0x compression. I'd turn it off there (no point in having it on).
Furthermore, I would say that because of the CASL design, one could make an argument that Nimble's performance can actually benefit from having compression enabled (for compressible data types). Think of it this way: with compression, we can fit more data into a single coalesced data stripe to flush to disk. The more data we fit in a stripe, the more data we can deliver to disk in a single flush/write operation. This in turn can equate to being able to handle more front-end I/O in the same amount of back-end flushes to disk. As a side benefit, since the compressed data takes up less sectors on disk, it would take less time to read from disk on a cache-miss.
Retrieving data ...