Re: database corruption

[Eric Sturdivant <sturdiva@umd.edu>]

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