SrvThreadBypassConfig Explanation

[kenchoo]

1. What do we actually lose when we bypass the wait for Oplock by setting "Sadmin config set SrvThreadBypassConfig=1"? Are those files ignored totally, i.e. solidcore will ignore them entirely?

2. Also, KB85156 states that this task should be performed on the clients. In my customer's environment, they encounter a 30 second wait trying to save files directly from any office application into a mapped drive. Saving to local drive is instant. However, dragging from local drive to mapped drive in explorer is instant. Saving to mapped drive from notepad.exe is instant too. We tested setting the config based on the KB on the clients but it doesn't resolve the issue. However, setting it on the server instantly fixes everything. Note that the file share is a clustered file share. Disabling solidcore also fixes the problem.

3. Can we get a detailed explanation on how the server giving out oplocks is affecting our solidcore? If a remote file has oplock and client endpoint has a cached copy, I assume winword on client machine should not be 'blocked' from performing any IO. How then is solidcore on the server somehow slowing it down? Or could this be a case that client has oplock, tries to write something to server 1, solidcore tries to read it, backend synchronous (just guessing) replication tasks try to perform something but is 'queued' behind solidcore, and hence no acknowledgement goes out to the client. Then eventually the locks timeout and things move instantly, hence clients encounter the 30 sec delay.

[bleeder · Accepted solution]

In case you're still watching this thread, McAfee recently added a note for this setting in KB85156.

NOTE: SrvThreadBypassConfig=1 resolves a deadlock thread issue with MACC and Windows Oplock (Opportunistic Locks). Enabling this feature configures MACC to bypass thread checks. Bypassing these thread checks prevents this type of deadlock from occurring and does not result in any loss of MACC product functionality.