Hi All,
I have a HSM filter driver which will restore the data from the remote server when the user access my stub files.
But when I open the stub files via map drive or UNC path, if I try to browse the map drive, it will take long time to open it, almost needs to wait for the completion of the read.
If I read the normal file with the same way, even with very large files, during the reading, I can open the map drive right away.
I run the file spy, but I didn’t see there are I/O was blocked to open the map drive.
Any suggestions?
Thanks
Tsang
Do you set the offline attribute (FILE_ATTRIBUTE_OFFLINE) on your stubbed
files? This lets Explorer know that it would be expensive to open the files
and sometimes this speeds up directory enumerations (e.g. Explorer won’t try
to generate thumbnails).
-scott
OSR
@OSRDrivers
wrote in message news:xxxxx@ntfsd…
Hi All,
I have a HSM filter driver which will restore the data from the remote
server when the user access my stub files.
But when I open the stub files via map drive or UNC path, if I try to
browse the map drive, it will take long time to open it, almost needs to
wait for the completion of the read.
If I read the normal file with the same way, even with very large files,
during the reading, I can open the map drive right away.
I run the file spy, but I didn’t see there are I/O was blocked to open the
map drive.
Any suggestions?
Thanks
Tsang
Thanks Scott.
Yes, I did setup the offline attribute for my stub files.
Also I found that if the file with offline attribute, the SMB server will read the file with normal FastIO read, then IRP_READ read.
Then I tested without the offline attribute, the SMB server will read with MDL read, the read will be a bit faster.
In both scenarios, if the read is not completed, it will hang there to open the map drive.
Thanks
Tsang
Break in and dump the threads in Explorer during the delay and see what they
are doing (!process 0 1F explorer.exe). Are you delaying recall until
someone opens for data access or are you doing it for all opens?
If Explorer has triggered a recall then you’re going to have to wait until
the recall is complete before you can continue to use Explorer. I don’t
think this is unexpected, about the best you can do is try not to recall
until absolutely necessary.
The MDL interface has to do with cached I/O versus non-cached, it shouldn’t
necessarily have anything to do with the offline attribute.
-scott
OSR
@OSRDrivers
wrote in message news:xxxxx@ntfsd…
Thanks Scott.
Yes, I did setup the offline attribute for my stub files.
Also I found that if the file with offline attribute, the SMB server will
read the file with normal FastIO read, then IRP_READ read.
Then I tested without the offline attribute, the SMB server will read with
MDL read, the read will be a bit faster.
In both scenarios, if the read is not completed, it will hang there to open
the map drive.
Thanks
Tsang
Thanks Scott again,
I only replace the read buffer with my data during the read I/O for the stub files, actually I did a test which I don’t do anything, but only sleep a half second in every read, it can simulate the similar problem which the explorer will hang there.
This issue doesn’t happen in Windows 2012 or Windows 10. It happens in Windows 7 and Windows 2008 R2.
I did break the computer and dump the threads of the explorer as you said, but the output is quite large, I will try to post with next thread.
Here is the thread of the Explorer which is enumerating the directory, but I can’t tell any special here.
THREAD fffffa800265f060 Cid 0a58.0b9c Teb: 000007fffff52000 Win32Thread: fffff900c068a010 WAIT: (Executive) KernelMode Alertable
fffffa8002c6bc10 NotificationEvent
IRP List:
fffffa8001b36010: (0006,01f0) Flags: 00060800 Mdl: fffffa800283aaf0
Not impersonating
DeviceMap fffff8a001a94640
Owning Process fffffa8001ad2680 Image: explorer.exe
Attached Process N/A Image: N/A
Wait Start TickCount 4266046 Ticks: 277 (0:00:00:04.328)
Context Switch Count 572 IdealProcessor: 0 LargeStack
UserTime 00:00:00.031
KernelTime 00:00:00.015
Win32 Start Address 0x000000007792f6f0
Stack Init fffff88004546db0 Current fffff880045460d0
Base fffff88004547000 Limit fffff8800453e000 Call 0
Priority 11 BasePriority 8 UnusualBoost 0 ForegroundBoost 2 IoPriority 2 PagePriority 5
Child-SP RetAddr : Args to Child : Call Site
fffff88004546110 fffff800026bbe42 : 0000000000000000 fffffa800265f060 fffffa8003f3ec28 fffff8800000000b : nt!KiSwapContext+0x7a
fffff88004546250 fffff800026cd1df : fffff8800364b4a8 fffff88002612000 0000000000000000 fffffa8003f3e938 : nt!KiCommitThreadWait+0x1d2
fffff880045462e0 fffff800029617ee : 0000000000000100 fffffa8000000000 0000000000000000 fffff88002612201 : nt!KeWaitForSingleObject+0x19f
fffff88004546380 fffff8000296186b : fffffa8003833501 fffffa80028409c0 fffffa80038334d0 fffff8a001db9da0 : nt!FsRtlCancellableWaitForMultipleObjects+0x5e
fffff880045463e0 fffff880026931e3 : fffffa8002c6bc10 fffffa8003833501 fffffa80028409c0 fffffa80038334d0 : nt!FsRtlCancellableWaitForSingleObject+0x27
fffff88004546420 fffff88002680f07 : 0000000000000001 fffff8a000000000 fffffa8000010000 fffff80000000025 : mrxsmb20!MRxSmb2EnumerateDirectoryFromCache+0x2ab
fffff880045464d0 fffff88003a5d4f3 : 0000000000010000 0000000000010000 fffff8a00a195b00 fffff8a00a195b00 : mrxsmb20!MRxSmb2QueryDirectory+0x1b
fffff88004546520 fffff8800365dd52 : fffffa80028409c0 fffffa8001b36001 fffffa8000000000 fffffa8000010000 : csc!CscQueryDirectory+0x49f
fffff88004546630 fffff8800365df9f : fffffa80028409c0 fffffa8001b36010 fffff8a00a195b00 0000000000000025 : rdbss!RxQueryDirectory+0x682
fffff880045466d0 fffff88003633684 : 0000000000000000 fffff88004546770 fffffa80028409c0 0000000000000001 : rdbss!RxCommonDirectoryControl+0xeb
fffff88004546730 fffff88003650b44 : fffffa8001b36010 fffffa800394d00c 00000000c0000016 fffffa8001b36010 : rdbss!RxFsdCommonDispatch+0x870
fffff88004546820 fffff880026202bc : fffffa8001b36010 00000000c0000016 fffffa8001b36170 fffffa800394d040 : rdbss!RxFsdDispatch+0x224
fffff88004546890 fffff880019e6271 : fffffa8003ebf010 fffffa8001b36010 fffffa8003e9f780 fffff8a0001269e0 : mrxsmb!MRxSmbFsdDispatch+0xc0
fffff880045468d0 fffff880019e4138 : fffff8a0001269e0 fffffa8003ebf010 0000000000000001 0000000000000000 : mup!MupiCallUncProvider+0x161
fffff88004546940 fffff880019e4b0d : fffffa8001b36010 fffff880019e2110 fffffa8002678890 0000000000000000 : mup!MupStateMachine+0x128
fffff88004546990 fffff88001038bcf : fffffa8001b361b8 fffffa8003ebf010 fffff88004546a20 fffffa80027e4b60 : mup!MupFsdIrpPassThrough+0x12d
fffff880045469e0 fffff880010376df : fffffa8002801640 fffffa8002678890 fffffa8002801600 fffffa8001b36010 : fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x24f
fffff88004546a70 fffff800029b3b2a : fffffa8001b36010 fffff88004546ca0 000000000a3ae368 fffff88004546bc8 : fltmgr!FltpDispatch+0xcf
fffff88004546ad0 fffff800026c5693 : fffffa800265f060 fffff88004546ca0 000000000a3ae368 fffff88004546bc8 : nt!NtQueryDirectoryFile+0x1aa
fffff88004546bb0 000000007795c08a : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KiSystemServiceCopyEnd+0x13 (TrapFrame @ fffff88004546c20) 000000000a3ae348 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 00000000`00000000 : 0x7795c08a
This issue looks like related to this hot fix:
https://support.microsoft.com/en-us/kb/2550581
but when I downloaded the hotfix, it can’t apply to my computer Windows 7x64 sp1 or Windows 2008R2x64, I got the right one as the instruction shows, no idea why it said it is not compatible with my computer.