I have been noticing over the past six + months or so an ever increasing number of volumes on our DR cluster generating volume efficiency errors. I don't understand this as I don't run efficiency jobs in DR. The destination volumes of course include whatever savings were obtained on the source, and I do have compaction enabled on the destination, but there are no scheduled efficiency jobs running.
I am looking at an example now. It says an efficiency job started last night at 10:02:03 and ended at 10:02:21 with a Failure because "Operation was stopped". Changelog usage is 0%. Stale Fingerprint Percent is 1.
Anyone else encounter this before and/or have any ideas? It doesn't appear to be a significant problem, but the main thing I want to reduce is all the alert noise, so I can focus on legitimate issues to resolve.
Here is a clean log for one volume's sis job, no errors:
[sid: 0] Info (sis start vault) [sid: 1614593546] Begin (sis start) [sid: 1614593546] Processing transfer data logs (94314583 log entries) [sid: 1614593546] Generating transfer change logs (82548031 log entries)
[sid: 1614593546] Sort (82548031 fp entries)
[sid: 1614593546] Dedup Pass1 (69042 dup entries) [sid: 1614593546] Dedup Pass2 (1774 dup entries) [sid: 1614593546] Sharing (0 return status) [sid: 1614593546] Stats (blks gathered 0,finger prints sorted 1671058788,dups found 69042,new dups found 1774,blks deduped 0,finger prints checked 0,finger prints deleted 0) [sid: 1614593546] End (330192124 KB)
Then, here's another from a different time with the error:
[sid: 0] Info (sis start vault) [sid: 1614720003] Begin (sis start) [sid: 1614720003] Processing transfer data logs (86548136 log entries) [sid: 0] Info (sis stop vault) [sid: 0] Info (Dedupe operation is pausing) [sid: 1614720003] Stats (blks gathered 0,finger prints sorted 0,dups found 0,new dups found 0,blks deduped 0,finger prints checked 0,finger prints deleted 0) [sid: 0] Error (Operation was stopped )
As you can see, no real explanation - it just pauses and then stops. The email alert gets sent when it sees "Operation was stopped". Any ideas?
No apologies needed @jcolonfzenpr , this is very helpful! I searched through the log but didn't find a case where LRE was in use, including specifically with several of the volumes that have been alerting. Having said that, I think you may be on to something. We only just recently upgraded to OnTAP 9.5 on both source and destination, and that may have had some kind of impact regarding the new "extended compression" setting.
Do you know how to determine if a volume is configured to set "extended compression"? I know the one I showed you revealed there is "extended compressed" data on the target volume, but does that mean it is configured to "run" on that volume or just that the type of data is there (i.e. as transferred from the source)?
I don't know if I mentioned that our source is an AFF system which may help make sense of this.
The second KB says "If a source volume uses Extended compressed data, the destination must be running ONTAP 9.5 or later for SnapMirror to maintain storage efficiency savings (LRSE), regardless of the destination's storage efficiency settings." We upgraded both systems to 9.5 on the same day so LRSE should be in use, and I show that it is.
It also says, "Since extended compressed data includes adaptive compression, enabling on a SnapMirror destination volume will result in an LRE transfer." (emphasis mine)
The key question here is: what does it mean by "enabling"? I couldn't find a setting that deliberately enables or disables this feature. Any additional help will be greatly appreciated!