Possible TDB/Samba optimizations.

John E. Malmberg wb8tyw at qsl.net
Thu Mar 27 04:13:05 GMT 2003


COLLOT Jean-Yves wrote:
>>I had not determined if the better approach to be would be to have
>>routines that used the TDB API, so that the UNIX SAMBA code would not
>>need to be changed, or if it would be better just to replace the UNIX
>>routines with OpenVMS specific routines.
> 
> 
> I think that the current TDB processing is OK for most usages (CONNECTIONS,
> PRINTING, etc...). Only the locking processing would be far better with the
> distributed lock manager.

Connections is one that I would want to move to use the LOCKING code. 
Connections must be removed from the table if a SMBD process crashed.

Cleaning out the connection file was one of the pains while debugging 
the 2.0.6 file.

> If we want to minimize the changes and the specifics in the standard Samba
> code, my opinion is that the best way to do that would be to completely
> rewrite the LOCKING.C and BRLOCK.C modules, keeping their current external
> API specs.

That would be one approach, and probably the most efficient for coding. 
  As long as there is someone to track the changes to the external API 
in the UNIX SAMBA code.

The other approach would be to put a wrapper around the lock manager to 
make it look like the tdb.  But that assumes that the tdb interface is 
stable.

> One the main issues, I think, would be to define how the lock manager will
> be used, because the amount of information currently kept in the TDB file is
> far bigger than the available 16 bytes of the lock value block.

I think that there is a way to have more bytes than that associated with 
a lock.  It would take some research.  Possibly sublocks.

I would not want to use global sections as a supplement since they can 
not be shared between cluster nodes as locks can.

-John
wb8tyw at qsl.network
Personal Opinion Only



More information about the samba-vms mailing list