eddyc Posted February 13, 2017 Author Posted February 13, 2017 Sorry to dig up and old post but I thought it would be useful to let everyone know what I found. Firmware changes made no difference to the freezing. After lots of testing, I eventually found that at x:45 every hour the dedup background sync would take place. When this would kick in, the network would completely lock up, but with this disabled the network would not freeze or exhibit any of the other strange behaviour. I don't know exactly what happened here as this has been configured with the background optimisation on since the servers were built back when 2012 R2 came out.
psydii Posted February 14, 2017 Posted February 14, 2017 Dedupe uses the volume shadow copy subsystem. The volume gets frozen momentarily when called. If the volume is very busy, the amount of change data exceeds the systems ability to complete the snapshot and fails. During this period users/applications see the volume lock up (freeze). See also: https://blog.workinghardinit.work/2014/07/01/windows-2012-r2-data-deduplication-leverages-shadow-copies-lastoptimizationresultmessage-a-volume-shadow-copy-could-not-be-created-or-was-unexpectedly-deleted/
psydii Posted February 14, 2017 Posted February 14, 2017 (Also, I'd wager you've redirected client appdata folders to this server)
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now