I have not personally tested this, but may be safe to use assuming the compression is handled at the OS or hardware level. I can set up some internal testing on this for you as well and will let you know what I find out.

Thanks Kyle, I'll wait for more info on this

I have read about this recently.

Reads are still fast. However, writes require decompression and recompression. So your CPU is going to go up. I dunno how much.

It works great for lots of reads and little files that rarely change.

I think SmarterMail is write intensive, but I would like to see results as well.

Finally, are we talking 10 percent storage savings or something like 90 percent storage savings?  Storage is dirt cheap so consider this too.

Thanks!

Ron

Hi Ron!

For space saving, it seems that using it with mail storage can save more than 60-70%.

On ours Servers we use only Enterprise NVME, so it isn't so cheap for us...

You're very welcome Gabriele. I was able to get this set up on a test environment where I have live data, and will be monitoring it for a few days or so to ensure there are no adverse effects, at which point I'll reach out to update you on my findings. Have a good one!

What about Data Deduplication?  On a SmarterMail Server.  This might not be as helpful unless many files are exactly the same.

Data deduplication is another thing to test, but I think that compression could work better because GRP and EML files are tecnically plain text files...

But I'm not sure, it's only my guess...

So far my environment is running well with compression in place on the drive, but the true test will be on an environment that receives email regularly and has connected clients. This might be better to test on a clone of your environment that you can use to do live client testing and long-term evaluations of the mail data itself. 

As to deduplication; I tested this a couple of years ago and found no issues in SmarterMail. That said, it was not as helpful as I'd hoped as there isn't a whole lot of duplication ongoing in these environments. This was also prior to changes to our FIle Storage system and elsewhere, so this may warrant a new test as well.