of slow file copy issues
from time to time you may just as well be unsatisfied with the speed of file copy over a network given your fast and efficient switching and network infrastructure and the new servers that has just come in and you are piloting these before production.
file copy as simple as it may seem by selecting a bunch and right clicking to choose Copy in explorer is a complex operation in the background for the operating system. the multilayered approach in handling IO requests within kernel mode, needs some understanding of the IO architecture of Windows to tackle these types of issues. most of the time you will find that 3rd party filter drivers, misbehaving user mode applications are a cause and when stripped of these additional layers of complexity you will see that most of the time Windows to Windows file copy is efficient.
isolation and the reproducibility of such an issue is important so as to find the component that is indeed slow. is copying the same file without Antivirus in place still slow, is it your specific application that is slow, do you see the same results when copying the file over the command prompt, or better yet can the issue be reproduced when the system is booted into Safe Mode with Networking(will abbreviate to SMN mode)? in SMN any 3rd party networking or other AV and similar filter drivers will be disabled. in Windows drivers interact with each other and for any given IO request there may be multiple drivers interacting within a driver stack to fullfill the request. SNM will help you get these additional 3rd party components out of the picture thereby help isolate the root component of the cause.
once you are certain the issue is reproduced reliably in SNM, you need to make sure if the server side is consistent in this sense as well. can you reproduce the same issue with another file server? if the answer is no, then the server will need investigating. slow responses for file requests over a network file server, might mean that the server is having local performance issues and it might just be hitting its own limits in terms of servicing a specific number of requests at a time.
this would require looking at a performance log collected for a day or two and then analyzing this log to see trends in memory, disk, network and processor usage. I'll try to address other aspect of file access performance in coming posts, until then happy SMBing.