We recently converted a file server from Windows Server 2003 to Windows Server 2012, and ran into performance problems with a share.
All client PCs in this case are running Windows 7.
We have a folder that the PCs check for software updates, and use the GetFileVersionInfo API to read the embedded version information from the files. (large folder, 17k files in it). If the version is different than what is already on their C: drives, CopyFile
is used to copy it down
As there are hundreds of PCs checking this folder, at times they collide. Normally when there is a collision, a lease break is sent to the 1st PC to inform it that it can no longer perform write caching. As these files are typically not being written to, I would expect the PC to immediately say 'ok', and life moves on - and that is the observed behavior the vast majority of the time.
Occasionally though what happens is that the 1st PC does not respond to the lease break for several seconds, and then issues a flurry of "file close" commands for both the file in question as well as a bunch of others. (no writes, no reads, no other operation).
My speculation is that the there is a hole between the time that the last application on the PC closes its handle and the dormant file scavenger cleans up the remaining open files with the server. I think if the lease break request is received in a windows related to that, that it neither responds to the break nor responds with a close immediately, instead essentially timing out and finally closing when it gets around to it.
Is there a way to correct this? (by tuning client/server configuration - obviously can change how version mismatch detection works to not 'typically' open the file for reading).
See wireshark trap for an example: http://bobknock.com/getfileversion_lease_break.pcapng