2 issues I've noticed through testing:
- [detectable on all directory sizes] Each directory listing is ~3-4x slower on average on v6.8 vs v6.72 (2.5s vs 0.7s for a 6k file directory)
- [detectable for very large directory sizes] Trying to open a single NONEXISTENT file in a 250k file directory on 6.8 (should be microseconds per attempt), every 100 or so attempts, it hangs for ~5s
Initially, thought it had to do with concurrent calls, but it doesn't. Concurrent calls are simply additive in terms of execution time and concurrency itself doesn't seem to be the problem, but it makes it more apparent.
This is the result of comparison testing of 6.8.0rc7 through stable vs 6.7.2 from a Windows 10 client on gigabit LAN. See SMB config readouts and Python code for benchmarking below.
[OLD POST PRE ADDITIONAL TESTING]
Noticing this on 6.8.0rc7 (previously using 6.7.2). I'm using a Windows 10 client and have a bunch of Python scripts that list files on an unRAID samba share over gigabit LAN. This slows down to a crawl (several seconds just to refresh a ~100 file directory listing, whether using Python or Windows built-in file explorer). Was running the exact same scripts on 6.7.2 without this issue.
Transfer speeds seem normal. When accessing from a different Windows 10 client (at the same time that the first client has many concurrent requests), the directory listings SEEM normal.
Were there any settings changed for SMB that I might be able to try tweaking?
Recommended Comments
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.