Linux smbfs and smbclient 3.0.0 and 2.2.3a timeout on contact

Dave Jones JONESD at
Mon Oct 20 22:18:25 GMT 2003

>It seems less and less likely that the particular version of client is
>at fault.  We are seeing the same results with Windows clients.  It used
>to be I could at least intermittently get mounts to work within a couple
>of seconds.  Today, I found I was unable to mount from the Alpha/VMS
>samba server at all, no matter how many times I retried.

What's the size of your unexpected.tdb file?  There seems to be a pathology in
vms_tdb.c from the unreclaimed index buckets that result from the cumulative 
adds and deletes to that file by nmbd.exe.  Smbd will search this file
sequentially if if misses a datagram it is expecting.

Example from an unexpected.tdb that was running 4 days:
   $ search unexpected.tdb garbagein/log/statistics

   Files searched:                 1       Buffered I/O count:         5
   Records searched:               4       Direct I/O count:         752
   Characters searched:          952       Page faults:               43
   Records matched:                0       Elapsed CPU time:  0 00:00:00.18
   Lines printed:                  0       Elapsed time:      0 00:00:03.50
   %SEARCH-I-NOMATCHES, no strings matched

Note that it takes 752 direct I/Os to search 4 records, get a few processes
doing this and the latency goes through the roof.  The keys for the the
records added to unexpected.tdb consists of a 32-bit hash of a timestamp with
sequence number which never repeats, so the index buckets fill up with entries
for deleted records.

I'm still trying to work out the best solution to this problem.  One appoach
would be to do a convert/reclaim on the file perodically.  Another would be
to find a way to specify a mask for the hash result (on a per-file basis) so
that only a limit number (~couple hundred) key values are used.  You could also
modify nmbd (the only program that does keyed access) so that the the timestamp
cycles every 17 minutes (1024 seconds), limiting your keyspace that way (the
expiration logic would need changed to use modulo arithmetic).

David L. Jones               |      Phone:    (614) 292-6929
Ohio State University        |      Internet:
140 W. 19th St. Rm. 231a     |               jonesd at
Columbus, OH 43210           |               vman+ at

Disclaimer: I'm looking for marbles all day long.

More information about the samba-vms mailing list