[Samba] Friendly Reminder: Huge number of small files performance regression from 3.5.16 to 4.6.5 with identical smb.conf

[awl1]

Hmm, in addition I just started wondering about the following:

As it obviously is my Windows client that creates and sends the SMB2 
requests, maybe it is rather Microsoft to blame for choosing to sending 
the "wrong"/suboptimal/poorly performing client-side SMB2 find request 
(namely SMB2_FIND_ID_BOTH_DIRECTORY_INFO with pattern "*" instead of 
SMB2_FIND_NAME_INFO with the particular file name about to be written? 
Can Samba influence the Windows client earlier on in the message 
exchange to send find requests differently?

And in case that is true that this is a shortfall of Microsoft's SMB2 
client as opposed to their SMB1 client, then how could that be fixed? 
Are there any secret registry entries to influence this, or would I need 
to raise an issue with Microsoft and document this?

Really interesting... ;-):-(

I will now move forward and try to execute the same client scenario from 
a Linux environment (will boot the exact same client-side PC hardware 
into Ubuntu 16.04), do another tshark recording from there and report 
back (probably tomorrow or on Monday) what this might tell us...

Best regards,
Andreas


Am 15.07.2017 um 19:13 schrieb awl1 via samba:
> In this case, the Find operation does not look for the particular file 
> name that is about to be written, but seems to try and list the whole 
> current directory's content with a pattern of "*". Note that, looping 
> through the 2000 files to be written, the length of the Find Response 
> above increases (significantly!) with every file successfully copied: 
> When copying file number 1000, the Find Response sends back a list of 
> all 999 files that have been successfully copied to this directory 
> before, and this list of 999 file names is not needed for any 
> meaningful purpose, as the goal seems to be to check whether file 
> number 1000 already exists in this list of 999 files (which it of 
> course never does!) or not.
>
> The last call to SMB2_FIND_ID_BOTH_DIRECTORY_INFO that is contained in 
> the traces has a response length of about 64kB (containing filenames 
> that have already been written to the target directory but are not 
> needed/helpful in any way) and interestingly does not return 
> "STATUS_NO_MORE_FILES", but "STATUS_INFO_LENGTH_MISMATCH", maybe 
> because the buffer size for the result of the pattern lookup is only 
> 64kB!?