[Date Prev][Date Next]
RE: PLEASE HELP! maximum size of DB in 2.0.7
We're having similar problems trying to support a similar number of
entries using openldap-2.0.15 and Berkeley db-3.3.11. On a Red Hat
linux 6.2.4 (2.2 kernel) machine we hit a db file system limit @ 2GB
which is obviously an os/filesystem limit (i can't manually create a
bigger file on the machine).
On a FreeBSD 4.4 machine we hit a db file size limit of 4GB. As i can
manually create files > 4GB on this machine, i can only assume this is a
limit imposed by either openldap or berkeley db.
After seeing the following coming out of the configure script for
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... no
checking for _LARGE_FILES value needed for large files... no
and seeing the thing on the sleepycat website that db's of upto
256TB are supported i'm making the very rash assumption that it's not
the berkeley db backend.
Before i start delving into the source code, splitting the database or
using subreferrels etc. etc., can anyone throw any light on what's
imposing the limit and/or any simple workarounds?
Thanks in advance,
Incidently whilst i'm on the topic is there any reason why given:
sizeof(long)=4, sizeof(long long)=8, sizeof(off_t)=8
long fseek(FILE *stream, long offset, int whence);
off_t lseek(int fildes, off_t offset, int whence);
I can no longer use the fseek()/ftell() functions correctly, but can use
lseek(), on files over 2GB???
> -----Original Message-----
> From: Dan Shriver [SMTP:firstname.lastname@example.org]
> Sent: Monday, August 27, 2001 4:22 PM
> To: openldap-software@OpenLDAP.org
> Subject: PLEASE HELP! maximum size of DB in 2.0.7
> We recently were trying to add 5 million entries to a directory
> server on a system with XFS filesystem and openLDAP 2.0.7. At
> when the db grew to 2^31 it refused to accept any more entries.
> A ~2Gig file is far too small for us. What is the workaround?
> Is this bug just in 2.0.7 (we did not try loading 2.0.11 on the
> other box since it is a production machine, but if we do deploy
> with openLDAP we plan to use 2.0.11).