We have a few customers who were hit by that problem. You can see it if your "sis status -l" prints out incredibly huge numbers for "stale metadata" (in one case we had like 3500% stale metadata, but everything over 30% or so might indicate a problem)
If you're hit by that bug, I found that the only solution to 100% fix it is the following:
disable SIS on the volume(s) in question:
sis off /vol/volumename
upgrade OnTap to a newer version (8.1.2P4 is recommended as per the KB article, but newer is better, I'd suggest going directly to 8.1.4Px)
delete the SIS database
priv set diag; sis reset /vol/volumename
sis on /vol/volumename; sis start -s /vol/volumename
This has always fixed it for us. Note that we had a few cases with 8.1.2P4 where a simple "sis start -s" after the upgrade did not help; we had to do a "sis reset"
Yes, indeed. A managed services client had a LUN go offline because of this. Looking at the used storage, I couldn't figure out where it all was. One support case later and I find out this is the problem. The volume had about 700GB of stale metadata which probably took 8 hours or so to reduce. We found the bug after we upgraded to 8.2.1 from a buggy 8.1.2 release. It just so happened the volume filled up the morning after the upgrade. Awesome timing.
Please consider marking this answer "correct" or "helpful" if you found it useful
We originally engaged NetApp performance, because when we tried to commit VMware snapshots with memory snapshot it would completely paralyze our controllers. Now that we have upgraded and ran dedup twice to remove the stale fingerprints our issue is not more. We're able to commit the snapshots now and the controllers keep rolling.
Not sure if there was another bug or the stale fingerprints. Either way, not fun.
I have found our answer in bug 931439. It is new and very much still under investigation but Ill outline whats going on. When you do a copy in this manor Windows tries to create a SIS link instead of rehydrating the file immediately.
We can see that this is the case from the trace in packet 1842.