Performance issue on SMB share with Windows 10

Tournier Jérôme 0 Reputation points


I have some Windows 10 workstations with a SMB3 mounted share (on a Windows server) containing a directory structure with ~15k files.

When doing a recursive listing, the command (dir /s /b /a A: > list.txt) run in ~20s.

When doing a same test from a linux workstation with a mount point to the same share, the command (find /mnt/tmp/ > list.txt) run in ~5s.

Do someone have an explanation on that and how can I solve this issue ? This is very problematic to our Windows users to have such response delay.


Windows 10
Windows 10
A Microsoft operating system that runs on personal computers and tablets.
9,464 questions
Windows Hardware Performance
Windows Hardware Performance
Windows: A family of Microsoft operating systems that run across personal computers, tablets, laptops, phones, internet of things devices, self-contained mixed reality headsets, large collaboration screens, and other devices.Hardware Performance: Delivering / providing hardware or hardware systems or adjusting / adapting hardware or hardware systems.
1,458 questions
0 comments No comments
{count} votes

1 answer

Sort by: Most helpful
  1. Gary Nebbett 5,426 Reputation points

    Hello Jérôme,

    The difference is probably attributable to the "programs" that perform the recursive listing and is not directly related to the operating systems (Windows vs. Linux).

    Network and/or event tracing can be used to gain insights into what the programs are doing and where the time goes.

    I don't have a Linux system to check the "find" command, but analysing the "dir /s /b /a" command provides some hints as to why it is slower. It appears to traverse each folder/directory twice: once to obtain the names of the entries in the folder/directory and once to identify folders/directories for recursion. Furthermore, for each directory discovered, two queries for properties are made (FileStandardInformation, FileBasicInformation) even though the data is not needed when the "/b" qualifier is present.

    The Windows "dir" command is not necessarily badly coded - it appears that emphasis was given to flexibility and reusability. This is normally not a problem, but mapping this style to network protocol operations on large trees reveals a performance problem.

    It would be possible to write a program that is as quick as Linux "find" and it might be possible to find some public domain utility that is coded that way; however, it would not be easy to convince your users to use it.