Reputation: 31
While doing performance analysis on some source code, I noticed both CreateFile and fopen to be taking an unusually long time to complete on remote files.
Digging in further with wireshark, I discovered that when either of the two functions are used to open a file for reading, the entire contents of the file (up to approximately 4MB) are being read. Let me also note that neither function returns until the SMB2 read operations are completed (which takes up approximately 99% of the elapsed call time).
Is there anyway to prevent this behavior? Can anyone explain what's going here?
.. ..
Example:
HANDLE h = ::CreateFile( "\\\\Server1\\Data0\\CRUISE_DATA.bin", GENERIC_READ, FILE_SHARE_READ|FILE_SHARE_WRITE, NULL, OPEN_EXISTING, FILE_ATTRIBUTE_READONLY, NULL );
From Wireshark:
SMB2 426 Create Request File: Jim\Data0\CRUISE_DATA.bin
SMB2 386 Create Response File: Jim\Data0\CRUISE_DATA.bin
SMB2 171 Read Request Len:65536 Off:0 File:Jim\Data0\ CRUISE_DATA.bin
SMB2 1434 Read Response
...
...
SMB2 171 Read Request Len:65536 Off:3735552 File: Jim\Data0\CRUISE_DATA.bin
SMB2 1434 Read Response
Upvotes: 2
Views: 517
Reputation: 31
It was definitely scanning for something... virus scanning actually. Once I turned off my virus scanner and repeated the test, the behavior went away. Apparently the real-time protection scans every file as it is opened within a given process. The least it could have done is updated the local cache ;)
This issue has stumped us for a while now. It figures that the day after I post the question, the answer falls in our laps. Anyway, I hope this helps someone else.
Upvotes: 1
Reputation: 101774
You could try some of the CreateFile
flag options: FILE_FLAG_RANDOM_ACCESS
and/or FILE_FLAG_OPEN_NO_RECALL
. FILE_FLAG_NO_BUFFERING
might also help but it requires sector aligned I/O.
Newer versions of Visual Studio maps R
in the fopen mode string to FILE_FLAG_RANDOM_ACCESS
.
Upvotes: 0