search for: smb2_find_id_both_directory_info

...hat requires > significant work to understand and may or not be possible to resolve. Note that I have tracked down the issue to what I believe to be the root cause, and the root cause is NOT an issue in Samba, but an issue with Microsoft's SMB2/SMB3 client that uses completely inefficient SMB2_FIND_ID_BOTH_DIRECTORY_INFO requests in SMB2/3 as opposed to efficient FIND_FIRST2 requests in SMB1: The main parts of my analysis of the issue are contained here: https://lists.samba.org/archive/samba/2017-July/209749.html https://lists.samba.org/archive/samba/2017-July/209750.html https://lists.samba.org/archive/samba/20...

...;significant work to understand and may or not be possible to resolve. > Note that I have tracked down the issue to what I believe to be the > root cause, and the root cause is NOT an issue in Samba, but an > issue with Microsoft's SMB2/SMB3 client that uses completely > inefficient SMB2_FIND_ID_BOTH_DIRECTORY_INFO requests in SMB2/3 as > opposed to efficient FIND_FIRST2 requests in SMB1: > > The main parts of my analysis of the issue are contained here: > > https://lists.samba.org/archive/samba/2017-July/209749.html > https://lists.samba.org/archive/samba/2017-July/209750.html > https:...

...ery single response. Also, in case it indeed were a client-side cache, this cache would also need to be silently concurrently updated with every Create request/response cycle, because the number of files in the server-side directory always grows by the one file just written between one call to SMB2_FIND_ID_BOTH_DIRECTORY_INFO and the next... Thanks & best regards Andreas

Hi again, Jeremy, and hi to all commercial customers of Samba supporting companies on this list, ;-) Am 18.08.2017 um 20:18 schrieb Jeremy Allison: > What I mean is what you're asking is interesting, and I might get time > to look at this, but I can't give any guarentees. Work priorities and > any security issues always have to come first. If people *need* a > guaranteed

...es" and subsequently removes 100 files. The network captures show Linux clients just performing the required operations, including `SMB2_FILE_INTERNAL_INFO` and `SMB2_FILE_BASIC_INFO` requests appearing exactly 100 times each, whereas Windows clients perform in addition several expensive `SMB2_FIND_ID_BOTH_DIRECTORY_INFO Pattern: *` queries on the destination folder as well as on its parent (we counted 600+ such requests). The latter cause a remarkable performance loss, especially when the storage exposed via Samba is a network file system itself. As the mentioned thread seems to have been moved to the samba-te...

...ase it indeed were a client-side cache, this cache would >> also need to be silently concurrently updated with every Create >> request/response cycle, because the number of files in the >> server-side directory always grows by the one file just written >> between one call to SMB2_FIND_ID_BOTH_DIRECTORY_INFO and the next... > That's exactly what directory handle leases are. They're > oplocks for directories.

...esponse cycles over the network goes down - Wireshark pcapng file size is even slightly larger!!! (so it is NOT client-side caching on the Win SMB2 client side that does the trick), but the Windows SMB2 server "only" responds much faster to the infamous (and unnecessary/imperformant) SMB2_FIND_ID_BOTH_DIRECTORY_INFO requests with Pattern "*" - which probably means that the Windows SMB2 server does some caching here. In order to write the ~ 1000 files in my old test scenario, the total packet capture size for a SMB1 client against both a Samba or a Windows SMB1 server is about 10 MB, while the tot...

...> Also, in case it indeed were a client-side cache, this cache would > also need to be silently concurrently updated with every Create > request/response cycle, because the number of files in the > server-side directory always grows by the one file just written > between one call to SMB2_FIND_ID_BOTH_DIRECTORY_INFO and the next... That's exactly what directory handle leases are. They're oplocks for directories.

...bsequently removes 100 files. The > network captures show Linux clients just performing the required operations, > including `SMB2_FILE_INTERNAL_INFO` and `SMB2_FILE_BASIC_INFO` requests > appearing exactly 100 times each, whereas Windows clients perform in > addition several expensive `SMB2_FIND_ID_BOTH_DIRECTORY_INFO Pattern: *` > queries on the destination folder as well as on its parent (we counted 600+ > such requests). The latter cause a remarkable performance loss, especially > when the storage exposed via Samba is a network file system itself. > > As the mentioned thread seems to have been...

On 15/10/2020 09:46, Ralph Boehme wrote: > Am 10/15/20 um 9:30 AM schrieb Giuseppe Lo Presti via samba: >> Anyone knowing what happened at the time within samba-technical (if it >> can be disclosed)? > > iirc I tried to look into this offlist with the OP and actually spent > considerable time back then trying to reproduce the issue, but couldn't. > > I can't

...Filename: PathName\Modified\To\Protect\Customer\Sensitive\Data Blob Offset: 0x000001f0 Blob Length: 48 ExtraInfo SMB2_CREATE_QUERY_MAXIMAL_ACCESS_REQUEST SMB2_CREATE_QUERY_ON_DISK_ID SMB2 (Server Message Block Protocol version 2) ----------------- Then the client does a SMB2_FIND_ID_BOTH_DIRECTORY_INFO to list the contents of the directory...followed by this...It opens the same path without explicitly asking to open a directory (Neither 0x1 nor 0x40 is set in the Create Options). ---------------- Frame 65263: 682 bytes on wire (5456 bits), 682 bytes captured (5456 bits) on interface \Device\NPF_...

...d Rowland advised to strip down my smb.conf as much as possible, I haven't yet tried with "hide unreadable = no". Do you indeed mean to say that setting "hide unreadable = no" on the Samba *server* might indeed cause a difference in the way the Windows *client* sends its SMB2_FIND_ID_BOTH_DIRECTORY_INFO commands? This would mean that client and server would have to previously explicitly negotiate about the fact whether the server should hide unreadable files ("hide unreadable"), and make the Windows client decide to send a different client-side SMB2_FIND_* command with less performan...

Hi Alain, many thanks for responding! :-) Unfortunately, it's not that easy: In my case, the performance difference/regression between SMB1 and SMB2/3 is unrelated to any smb.conf settings, and even unrelated to Samba versions. It looks like Microsoft has introduced a performance bug with the way that their Windows SMB2/3 clients handle files with many entries, and this performance hit