2.2.0 development: tdb diskspace leak?

[Jeremy Allison]

David Lee wrote:
> 
> On our Solaris 2.6 test system, with a CVS version of Samba 2.2.0 from
> around October 24th, the file "unexpected.tdb" seems to be growing and
> growing and ... (you get the picture).  A few days ago it exceeded 9MB.  I
> restarted Samba (and cleared the file during that), but it is now up to
> nearly 1MB and still growing.  This server itself has been almost
> completely dormant during this period, although it is on a busy network.
> 
> But using "tdbtool" to examine the file usually shows only one or two
> active records in there (occasionally a few more).  The strings
> "\MAILSLOT\BROWSE" and "\MAILSLOT\NET\NETLOGON" seem to occur in the
> records.
> 
> So is there a known diskspace leak somewhere in the tdb code?  (A question
> primarily about code development.)  Hopefully the answer is "known and
> fixed".  But if not, any hints as to how to begin to tackle its
> investigation?

No it's not actually a leak, but a problem we need to address
soon. The problem is that if a tdb keeps getting full it will
allocate more space for records, which it will never free. The
space is not leaked - just allocated as "free" space - like a
growing malloc pool. The only way to trim it is to copy all the
entries into another db and then atomically rename. Currently this
is done with the unexpected db when nmbd is restarted.

The unexpected db stores all UDP 137/138 packets that Samba
receives that the original code wasn't expecting (ie. not a
reply to anything sent, or a packet not sent specifically
to this machine). We used to throw these packets onto the
floor, but we store them now due to a bug in WinNT where
it replies incorrectly to UDP 138 packets - by hardcoding
the reply port to 138 instead of the source port of the request.

The unexpected packet db allows nmbd to be running (and
bound to port 137/138) and for client tools that are not
bound to these ports to send requests out and receive the
replies correctly - nmbd gets the responses and puts them
into unexpected.tdb for the client tools to pick them up.

What seems to be happening in your case is that there is
a flood of packets on 137/138 that nmbd is storing in the
unexpected db - now periodically it does go through and
delete them when they've aged too much, but the allocated
space remains.

The fix is to monitor the tdb size and get nmbd to initiate
trim operations when it grows too large. I'll look into this
code.

Jeremy.

-- 
--------------------------------------------------------
Buying an operating system without source is like buying
a self-assembly Space Shuttle with no instructions.
--------------------------------------------------------