Re: database corruption

[Eric Sturdivant]

On Thu, 22 Feb 2007, [ISO-8859-1] Love H?rnquist ?strand wrote:

Since the iprop log contains key information I don't want to ask
for it, can you dump the database with dump_log and see
where it break and then try do figure out how the last entry
is broken.

The each entry in iprop log ahve this format, the first entry operation
is a NOP (no operation).

/*
* A log record consists of:
*
* version number                4 bytes
* time in seconds               4 bytes
* operation (enum kadm_ops)     4 bytes
* length of record              4 bytes
* data...                       n bytes
* length of record              4 bytes
* version number                4 bytes
*
*/

Love



It looks like 578 bytes of an incomplete log record got dumped directly 
after
version #2684610631

I can see all the parts of that record (as can dump_log), which ends with 
the
length and version number:
len: 00002a0  (672)
ver: a003e847 (2684610631)

This is followed by:
len?: c19993a2 (3248067490) which we aren't even close to as far as being 
a
valid version number

searching a bit further down I end up with what looks like the tail end of
this 'bogus' record, which ends like this:

len?: 000004de (1246)
ver?: a003e847 (2684610631)

This is then followed by what appears to be a correct record:

ver: a003e848 (2684610632) which is the next version number
time: 459a82d4 (this is consistent with the previous log entry)
op: 00000005 (modify)
len: 000002a0 (672, consistent w/other modify records)
etc...

this record ends correctly (with the matching len/ver pair).

If it helps, heimdal is linked against BerkeleyDB 3.2.9, and we are 
running on solaris 9 (sparc)


--
Eric Sturdivant
University of Maryland
Office of Information Technology
Distributed Computing Services