Date: Tue, 13 May 2008 11:41:39 -0400 From: "Kurt J. Lidl" <lidl@pix.net> To: Jeremy Chadwick <koitsu@freebsd.org> Cc: freebsd-hackers@freebsd.org, Anthony Pankov <ap00@mail.ru> Subject: Re: BDB corrupt Message-ID: <20080513154137.GA28842@pix.net> In-Reply-To: <20080513121452.GA70860@eos.sc1.parodius.com> References: <op.uavxx8ip2n4ijf@duckjen.nextgentel.no> <9FC19AC2-DAD8-418C-8B9C-F129DEC58CEF@gmail.com> <15336578.20080512123806@mail.ru> <200805121153.00809.jonathan%2Bfreebsd-hackers@hst.org.za> <1663320218.20080512223531@mail.ru> <20080512152430.3720683e@mbook.local> <2117635718.20080513154406@mail.ru> <20080513121452.GA70860@eos.sc1.parodius.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, May 13, 2008 at 05:14:52AM -0700, Jeremy Chadwick wrote:
> On Tue, May 13, 2008 at 03:44:06PM +0400, Anthony Pankov wrote:
> > If concurrency is the only problem then:
> > 1. ?an data corruption be avoided? Or this is impossible?
> > 2. How?
>
> Use Sleepycat/Oracle DB instead? The libc DB1.x, despite being
> "mature", really should be deprecated in some manner.
This catapults back into the arena of "stuff that isn't in the
base system". Not to mention I'm not sure that the Oracle BDB
license would allow bundling in the OS as a binary. I doubt it,
but that's a different bikeshed to paint :-)
> I'm sure there are others I've forgotten, but the only thing I can think
> of in the base system which relies on DB1.x is sendmail (which IMHO
> should really be removed from the base system and replaced with a small
> standalone mailer -- but that's been discussed in a previous thread in
> the past). Even "simple" ports like postgrey pull in db41, even though
> they could technically "work fine" with DB1.x.
Well, on a 7.0 machine, it looks like the following:
/etc/mail/aliases.db
/etc/{s,}pwd.db
/usr/share/misc/{termcap,vgrindefs}.db
And of course, nvi uses the db code's recno interface
to do all its work.
> > If all BDB readers would use O_SHLOCK and all writers O_EXLOCK is it
> > guarantee for data integrity?
>
> The corruption I've seen in the past results in DB operations failing
> for no particular reason ("what do you mean those are all the records?
> No! I just inserted a bunch more!"). It turns out some of the data in
> the actual .db file is corrupt -- even when locking is used everywhere.
> It's as if the code has some weird bug where it'll write bogus data to
> the file for some reason.
There are known problems with certain keys corrupting the DB 1.8x
series code. In fact, the "release" of the 1.86 was an attempt
to solve this problem when the KerberosV people at MIT found
a repeatable key insert sequence that would corrupt things.
(Or at least that's what I remember, it was a long time ago, and
I might have the details wrong.)
-Kurt
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080513154137.GA28842>