heath.kehoe at intermec.com
Mon Jun 19 19:30:58 UTC 2000
>after running OVDB for about a month using 2.3 BETA 05/13 I started to
>Jun 16 03:19:04 news2 expireover: OVDB: expiregroup: c_get:
>Jun 16 03:26:18 news2 expireover: OVDB: expiregroup: c_get: File too
>Jun 16 14:12:31 news2 innd: OVDB: add: db->put: File too large
>Jun 16 14:14:11 news2 innd: OVDB: add: db->put: Input/output error
>Jun 16 14:14:49 news2 innd: OVDB: add: db->put: Input/output error
>I have rebuilt using 2.3 BETA 06/15 and zapped the spool. If this
>re-occurs, I will let you know.
I'm guessing that one of your ovXXXX files hit the 2GB mark.
If you increase your setting of 'numdbfiles' in ovdb.conf, the
data will be spread out among more ovXXXX files, so they won't
get as large. If you want to change numdbfiles, you will have
to erase your existing overview database first, and then rebuild
>Unfortunately, I didn't notice the errors with the OVDB, and blew it away
>before getting a du and ls -al of the directory. We had been seeing
>occasional deadlocks of the OVDB solvable by:
>I'll send an update if I see any OVDB deadlocks or corruption again.
>#define DB_VERSION_STRING "Sleepycat Software: Berkeley DB 3.0.55:
>er 15, 1999)"
There is a new version of Berkeley DB available, 3.1.14, which fixes
the known bugs in 3.0. Upgrading to 3.1 may fix the deadlock problem.
More information about the inn-workers