tobold.org

correct • elegant • free

△ comp.lang.perl △

◅ [Q]: flocking file from read to write?

DBM under Perl 5 ▻

dbm error and weirdness

In article <3140292C.774F@sv.poppe.com>,
Jeff Weitzel  <jweitzel@sv.poppe.com> wrote:
>First, does anyone recognize this error?

Sorry, no.  I would guess, however, that you have exceeded the 1024
byte limit on keys + values for all keys that hash together.

>A second, possibly related problem is that perl doesn't seem to be
>writing properly to the dbm file. There are about four hundred
>records in that thing, none of which are larger than a Kilobyte, and
>the thing is taking up hundreds of megs! Anyone recognize this?

This is normal (and documented): NDBM uses sparse files, that is,
files whose apparent is greater than the actual number of disk
blocks they use.  Sparse files contain "holes", blocks which are
not allocated on disk, and read as all zeroes.  (The main problem
with sparse files is that few Unix utilities expect to encounter
them, so `cp', for instance, will fill in the holes.)  You can use
`ls -ls' to see both the apparent size and the number of disk blocks
used.

My advice would be to forget NDBM, and use Berkeley DB or GDBM
instead.  They have no limits on the size of data you can store,
and avoid very sparse files.  (DB btree files are not sparse at
all; DB hash and GDBM (yes, despite what the documentation says)
files are "slightly" sparse.)  See `perldoc DB_File' and `perldoc
GDBM_File' for more information.  Experiments I've done suggest
that DB btree is generally the fastest of the three.

Tim.
--
Tim Goodwin   | "Those who will not study history are
Cambridge, UK | doomed to debug it." -- Barry Shein

Original headers:

From: tim@pipex.net (Tim Goodwin)
Newsgroups: comp.lang.perl.misc
Subject: Re: dbm error and weirdness
Date: 14 Mar 1996 17:36:35 GMT
Organization: Unipalm PIPEX
Message-ID: <4i9lf3$7oi@wave.news.pipex.net>
References: <3140292C.774F@sv.poppe.com>

△ comp.lang.perl △

◅ [Q]: flocking file from read to write?

DBM under Perl 5 ▻