Dead space in sessionid.tdb

[Hemanth Thummala]

Hi Volker,

We are running 3.6.12 + (critical and security fixes).
Have seen few threads and patches related to cleaning up of messages.tdb
and locking.tdb files. Here is one we found for cleaning up dead records in
messages.tdb file

https://lists.samba.org/archive/samba-technical/2014-April/098856.html

But this is specific to messages.tdb file cleanup. Should we have similar
cleanup routine for sessionid.tdb as well?

Also would like to understand the reason for having huge dead record at one
point. Any pointers here will be really helpful.

Thanks,
Hemanth.



On Fri, Aug 22, 2014 at 6:15 AM, Volker Lendecke <Volker.Lendecke at sernet.de>
wrote:

> On Fri, Aug 22, 2014 at 06:22:21PM +0530, Shilpa K wrote:
> > Hello,
> >
> > We have a problem with sessionid.tdb where it has grown to a large size:
> >
> > # ls -l sessionid.tdb
> > -rwxrwxrwx  1 root  wheel  1618509824 Aug 12 14:48 sessionid.tdb
> >
> > But it does not occupy much disk space.
> >
> > tdbtool "info" command shows that there is one dead record of huge size:
> >
> > tdb> info
> > Size of file/data: 1618509824/160681
> > Number of records: 101
> > Smallest/average/largest keys: 14/14/15
> > Smallest/average/largest data: 1576/1576/1576
> > Smallest/average/largest padding: 401/401/402
> > Number of dead records: 1
> > Smallest/average/largest dead records: 1618305000/1618305000/1618305000
> > Number of free records: 1
> > Smallest/average/largest free records: 464/464/464
> > Number of hash chains: 131
> > Smallest/average/largest hash chains: 5/13/22
> > Number of uncoalesced records: 0
> > Smallest/average/largest uncoalesced runs: 0/0/0
> > Percentage keys/data/padding/free/dead/rechdrs&tailers/hashes:
> > 0/0/0/0/100/0/0
> >
> > tdbtool "check" command shows that most of the space occupied by the TDB
> is
> > dead space:
> >
> > tdb> check
> > Dead space at 204800-1618509824 (of 1618509824)
> > Hashes do not match records
> > Integrity check for the opened database failed.
> >
> >
> > In the freelist, one of the record is of big size too:
> >
> > tdb> free
> > freelist top=[0x604e2420]
> > entry offset=[0x604e2420], rec.rec_len = [0x00000fa8 (4008)] (end =
> > 0x604e33c8)
> > entry offset=[0x6046e1a0], rec.rec_len = [0x000007c8 (1992)] (end =
> > 0x6046e968)
> > entry offset=[0x604e0c80], rec.rec_len = [0x00000fa8 (4008)] (end =
> > 0x604e1c28)
> > entry offset=[0x6046ca00], rec.rec_len = [0x00000fa8 (4008)] (end =
> > 0x6046d9a8)
> > entry offset=[0x4d2d3000], rec.rec_len = [0x131999e8 (320444904)] (end =
> > 0x6046c9e8)
> > entry offset=[0x000002b8], rec.rec_len = [0x000001d0 (464)] (end =
> > 0x00000488)
> > total rec_len = [0x1319d278 (320459384)]
> >
> >
> > Could you please let me know what are the possible circumstances which
> can
> > lead to dead space in a TDB?
>
> This could be the recovery area that will be created during
> a tdb_repack, whatever calls that.
>
> What version are you running? We've been fixing a few bugs
> in that area in the last year or so.
>
> With best regards,
>
> Volker Lendecke
>
> --
> SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
> phone: +49-551-370000-0, fax: +49-551-370000-9
> AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen
> http://www.sernet.de, mailto:kontakt at sernet.de
>