Mike, > If the path requested does not exist the server MUST search the files > within each directory and do a case insensitive comparison on each to > prove that the file does not exist. However, if the file does exist, > usually the case provided is correct. So as an optimization you can just > stat(2) for that component and only do the directory listing search if > it fails. Additionally if you simply stat(2) the entire path requested > at the very beginning and it exists you can skip the multiple stats and > directory searches altogether. > > I'm not terribly familar with Samba but apparently the version you're > using lacks some of these optimizations.
I'm pretty sure Samba3 does have these optimisations (it did last time I looked), and certainly Samba4 does, but unfortunately there are cases where the client makes calls that don't allow this sort of optimisation. Perhaps the most common case is where a user on the client does "del *.*". In that case the client asks for a directory listing, then it asks to delete each file one at a time, but it provides the mangled (8.3) name for the file in the SMBunlink call rather than the full name. Samba tries to optimise this by keeping a reverse lookup cache from 8.3 name to long name (the so called "mangled cache"). As long as the cache doesn't fill, then this works well. If the cache does fill then things are not so nice. The code then falls back to a full directory search to do the mapping from 8.3 to full name. For the "del *.*" case this turns the whole operation into something that is O(n^2), which gets very very slow for large n. I am a proposed solution for this that I have on my todo list for Samba4. The solution is to make the cache size dynamic, but use a timer event to shrink the cache per connection when its not needed. So no matter how big the directory is Samba will always keep the whole directory in cache for a few seconds (probably 30 seconds or so), but will then shrink it after that time. It will also have to have a "number of directories in cache" limit to prevent DOS attacks on this mechanism. Cheers, Tridge -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
