Jump to content

Recommended Posts

Posted

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.

Posted

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/

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 account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...