config has: stat cache = yes case sensitive = no When a client does open or stat lots of files (virus scan or find on a share with 1.5e6 files) all the full pathnames go into the statcache until the process reaches its ulimit (128MB in my case). Then I get lots of: [2005/04/03 09:39:21, 0, pid=946416] smbd/statcache.c:stat_cache_add(132) stat_cache_add: Error storing entry PROFILE/FIEDERM7/SICHERUNG C/WETTERDATEN/KLIMA_SEIT_1971/KLIMA2000/DATEN/KLIMADATEN -> profile/fiederm7/Sicherung C/WetterDaten/Klima_Seit_1971/klima2000/daten/klimadaten The process seems to still work OK but slow, although I wonder how memory corruption is avoided finding this in tdb/tdb.c: 835 if (tdb->flags & TDB_INTERNAL) 836 tdb->map_ptr = realloc(tdb->map_ptr, tdb->map_size); 837 else There is no error checking! I suggest two things: 1: impose some limit on the size of the stat cache and remove older (or all) entries, when the limit is reached. 2: tdb shouldn't use realloc without checking for NULL. setting "stat cache = no" removes the problem for now.
Created attachment 1144 [details] Proposed patch.
I fixed the tdb problem, and here is a rate parameter : "max stat cache size" (in kb) that will limit growth. Please test and let me know. Thanks, Jeremy.
(In reply to comment #2) > I fixed the tdb problem, and here is a rate parameter : > "max stat cache size" (in kb) that will limit growth. if (sc_size && (sc_size*1024 > tdb_stat_cache->map_size)) { reset_stat_cache(); } Shouldn't this be the other way round: if (sc_size && (tdb_stat_cache->map_size > sc_size*1024)) { reset_stat_cache(); } Am I missing something?
No, you're completely right, I'm an idiot :-). Thanks. Jeremy.
(In reply to comment #2) > I fixed the tdb problem, and here is a rate parameter : > > "max stat cache size" (in kb) that will limit growth. > > Please test and let me know. I tested the corrected patch. The new parameter works as expected. Thanks
New parameter fixes the bug. Jeremy
sorry for the same, cleaning up the database to prevent unecessary reopens of bugs.