Antonio,
there are 2 mechanisms in SAMBA, which cause a performance penalty when handling/browsing/opening large directories:
- when accessing a file in any directory for the first time, SAMBA will fill it's directory cache, building a simple list of all file names within this directory. This list is used to later speed up wildcard accesses in that directory. Depending on the no. of files in the directory, building the file name list can take a while.
- when browsing a directory, SAMBA also fills it's stat (file) cache. As a Windows directory entry expects information like file access dates, file size etc. in addition to just the file name, this information needs to be obtained from the individual file headers in OpenVMS - again a somewhat IO intensive operation under OpenVMS.
Once the stat (file) cache is filled, things are getting a little better. But there are 2 problems with SAMBA V2.2.8 here:
* the stat cache handling of the directory tree is broken. This will cause the same file to be entered twice in different directories cache entries (once with /000000 included and once without). This causes the stat cache to not become effective starting the 3rd access to the directory. This is fixed in SAMBA V2.2.12.
* the no. of entries in the stat cache is limited to 16k files per directory. Once your directory grows beyond that no. of files, things get worse...
If you can keep the directory size small, SAMBA works quite well.
Volker.
