[Date Prev][Date Next] [Chronological] [Thread] [Top]

[Fwd: ldif2ldbm NEXTID=1 (again ;)]

--- Begin Message ---


Stuart Henderson wrote:

> I've just been rebuilding my ldap directory from an exported
> ldif file using ldif2ldbm. I realise this doesn't perform syntax
> checking, but since the entries were originally created using
> the LDAP protocol I don't see this as being a problem; the
> speed difference is significant for the 25k-entry directory
> I'm importing.
>
> Like some other posters to the mailing lists and authors of
> reports in its, I found that my NEXTID file contained the number
> 1 after completion (repeating the operation, I determined that
> the correct value was written initially, however this was later
> overwritten).
>
> This only occurred when building multiple indices concurrently
> (i.e. using the -j option) rather than serially. I'm using 1.2.10
> although I didn't find any relevant fixes in the current release.
>
> Would it make sense to disable -j for any future 1.2 releases?
> If left enabled, I'd suggest that documenting this behaviour in
> ldif2ldbm(8C) might save some frustration. It might also be a
> good place to explain to a wider audience about syntax checking :-)

I noticed this, too, but I didn't have time to work it out, because
I was
recovering the system after a crash. Anyway, it happened only for a high

value of parallelism, say 8. With -j 2 there is no problem. It sounds
like
that only when creating dn2id.xxx file the NEXTID value is updated
correctly, so the process that creates this file must finish later than
those that create other indices. As a consequence, if you use too many
processes, some of those that start with no valid NEXTID file may end
AFTER the dn2id.xxx process, resulting in an overwriting of the correct
file.

But this is only a guess; if nobody has a better answer, I'll try to dig
it out.

Pierangelo Masarati
<ando@sys-net.it>



--- End Message ---