This is most likely, as all have indicated before, a limitation using
the ndbm interfaces. The SLAPD code builds some index constructs
and stores these using the ndbm interfaces. We have found that there
is a 1024 byte limit on data stored using the ndbm interfaces and this
comes into play. Unfortunately, the code in SLAPD that builds the index
constructs is not sensitive to this 1024 byte limit (1024 bytes INCLUDES
the key AND data fields of the ndbm data) and at about the 128th or 129th
RDN under a higher RDN, the index array gets too large for the 1024 byte size
limit. This causes the ndbm dbm_store() routine to return errno
ENOSPC ("no space left on device").
We've hacked the code to "split" the array "sooner" than the code already
was set up to do to get around this problem. HOWEVER, SLAPD also appears
to store ALL attribute data for an entry within a single ndbm key/data
pair. This is more troubling in that it implies that an entry's total
information content (including attribute type information), when using ndbm,
cannot exceed about 1008 bytes. Code may exist to split an entry's data
over multiple ndbm key/data packets but I have not seen it yet.
I will second (third?) the concerns about using the ndbm routines in
SLAPD.
Regards,
/----------------------------------------------------------/
/ Tim Hahn /
/ DCE/MVS Development (607)752-6388/
/ Internal:hahnt@endicott Internet:tjh@vnet.ibm.com/
/----------------------------------------------------------/
--------------Original Message Follows-------------
> We are having the same problem with the 128 limit when we try to use ldif2ldb
m
> to create the ldbm database from an ldif input file. As soon as we add one
> more entry to the ldif file, we get the following error when we run ldif2ldbm
> on it:
>
> idl_insert_key: No space left on device
> stopping: child exited with status 1
>
> We are running it on a Sun Sparcstation 4 with Solaris 2.5.
> _____________________________________________________________________________
__
> From: Jochen Keutel on Tue, Jun 18, 1996 8:39 AM
> Subject: Re: Problems getting LDAP to work:RE
> To: Tim Howes
> Cc: ldap@umich.edu
>
> Hello,
>
> > Looks basically good to me, though I notice you are using ndbm.
> > ndbm is known to be evil on many many platforms. You might try
> > getting gdbm or berkeley db instead. I've seen ndbm fail in
> > a bunch of nonobvious ways (mostly due to size restrictions).
>
> this is also the experience I have. Just last week I tried to load
> about 320 organizationalUnits via "ldapadd -f /tmp/all_ous" into
> ndbm. (I use LDAP 3.3 on SINIX 5.42, machine ist RM600. (Risc))
> I could load one country, one organization and 128 (interesting number, BTW)
> organizationalUnits. The next ADD failed with operations error.
> slapd says:
> id2children_add( 2, 130 )
> => ldbm_cache_open(
> "//home2/ldap/ldapinst/ldap-3.3/ldbm_base/id2children.ndbm",
> 258, 600 )
> <= ldbm_cache_open (cache 1)
> <= id2children_add 0
>
> ...
> id2children_add( 2, 131 )
> => ldbm_cache_open(
> "//home2/ldap/ldapinst/ldap-3.3/ldbm_base/id2children.ndbm",
> 258, 600 )
> <= ldbm_cache_open (cache 1)
> <= id2children_add -1 (idl_insert)
> id2children_add failed
>
> This happens indepenently on the number of attributes I create indexes for.
>
> Are there any known limits for ndbm?
>
> (The background is: We have a X.500 server with about 30000 entries.
> I plan to use slapd as a "backup database" for our X.500 server. Once we have
> switched all Windows clients to use LDAP to access the X.500 server it would
> be very nice that we could start just slapd instead of ldapd if we get seriou
s
> problems with the X.500 server. Probably you'll recommend that we should
> use gdbm or a self-written database backend in slapd ...
> X.500 server is DIR.X 3.1 (SNI) which uses C-ISAM.)
>
> Bye,
> Jochen.
>
> ------------
>
> Dr. Jochen Keutel currently at: Deutsche Telekom
> duerr com-soft IZ Darmstadt
>
> Phone: +49 6151 818 579
>
> e-mail: keutel@u9ytb.iz-darmstadt.telekom.de
> 100.37805@germanynet.de
> X.400 : /C=de/A=dbp/P=telekom400/O=dmst03/OU1=08/S=osys-02
> WWW : http://www.geocities.com/WallStreet/3454
>
>
>
>