It's an legacy protocol issue, right !? But still present and never solved really, Just wanna ask the community if there is solution or workaround for this ?
Depends on context / ops that are problematic. Newer SMB1 perf will be necessarily pretty crap. SMB2/3 supports compounding of requests, but that depends on how well the client compounds. New linux kernel client should be pretty good, Windows 10 should also be good, MacOS will probably be pretty bad (not because of compounding, but because of increased SMB requests).
Except that aspect it may also correspond with ipsec & smb because my ipsec roadies perform pretty welll with all servicec except smb.
In the near future I will move to wireguard which may deal better with smb but I did not tested that yet. (wireguard & smb).
Beside that aren't there recomended tuning settings for smb which are relative safe to apply into the smb config to speed up things eg. TCP_NODELAY etc. ?
Btw. TCP_NODELAY is not in global here (running 12.0U8) and aio max threads is = 2 (smb default 100 ) ?
or is it default enabled in the current ssmbs version.....
Bring that topic back to life- Still unsolved for Windows 10 and Mac Clients;
Is wireguard here a solution regarding the lower overhead affecting samba performance ?
And or What about Webdav, could that be the solution for Roadies ?
Are there any reasons why not to create webdav shares in addition to smb shares in parallel or could that break things regarding locking and co. u know if users accesing shares simultaneously via smb and webdav ?
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.