[Date Prev][Date Next]
Re: slapadd -q (quick mode)
Hallvard B Furuseth wrote:
Quanah Gibson-Mount writes:
> <email@example.com> wrote: slapadd -q has been entirely safe
> for me as long. The point of that paragraph is that if you kill
> slapadd, or an error occurs during the slapadd, you will need to
> wipe the database and start over. Apart from that, it is
> completely safe. ;)
OK, then I suggest making its description a little less scary:-)
I suppose now that it has been used successfully for so long we can tone
down the warning. When we were still experimenting it seemed appropriate
to make it as scary as possible. ;)
>> Second, I'd like this option to be split: Assuming -q is safe to
>> use when creating a database from scratch which will be deleted
>> if slapadd fails, I'd like to turn off database checking but turn
>> on LDIF checking. I suppose that would mean adding either an
>> option which checks the LDIF despite -q, or an option which only
>> turns off database checking and not LDIF checking.
> I disagree. Slapadd -q as it is now can still be used safely with
> -c, which is entirely sufficient.
That's another issue. -c says what to do when an error is detected.
I'm suggesting better control over which error detection to disable.
In fact, only one check is disabled: the check for discontiguous
attribute values. Of course at this point, after all the profiling and
tuning we did, I think we could re-enable this check at all times
without a measurable performance hit.
> slapadd -q was added because of research done on how and why large
> database loads took forever, and adding new checks to make it take
> even longer are entirely counter intuitive.
I was not suggesting any new checking. I'm talking about better
control over which checking to disable. -q disables both database
checks and LDIF checks, I want the option of disabling only database
checks. Maybe someone else could have use for a way to disable only
LDIF checks, if they trust their LDIF but need database checking.
Though actually I would like an option for more LDIF error checking
too: Adding whatever check ldapadd does which is convenient to add to
slapadd, including a "verify" function in overlays like "unique", to
be called for each entry after the database is built and indexed.
Then I think you should just use ldapadd in the first place.
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/