dets with Mnesia question

Yariv Sadan yarivvv@REDACTED
Tue Aug 15 14:39:08 CEST 2006


I like this idea. I was also thinking maybe it would be possible to
use Mnesia's transaction capabilities to get the freelist consistency
"for free."

Here's a possible solution:

1) Make dets freelist management "pluggable" (otherwise, use Smerl to
hack it in runtime :) )

2) When used with Mnesia, each dets table would have an associated
disc_copies table for persisting the freelist.

3) Each dets write operation would involve a trasaction across the
dets table and the freelist table.

Advantage: the freelist would be kept in RAM for performance, and it
will also always have a consistent representation on disc. The safe
synchronization comes for free by reusing Mnesia's transaction

Fear: Mnesia's disc_copy tables are not suitable for storing the Freelist.

Fear2: Possible slow performance

What do you think?


On 8/15/06, Ulf Wiger (TN/EAB) <ulf.wiger@REDACTED> wrote:
> Perhaps one could implement an 'audit' mode where dets
> writes space management info to a disk_log file per
> dets file.
> /Ulf W
> > -----Original Message-----
> > From: owner-erlang-questions@REDACTED
> > [mailto:owner-erlang-questions@REDACTED] On Behalf Of Hans Bolinder
> > Sent: den 15 augusti 2006 10:22
> > To: erlang-questions@REDACTED
> > Subject: Re: dets with Mnesia question
> >
> > > My question is, would it be possible to shorten the repair time by
> > > modifing the dets startup procedure such that Mnesia could
> > "inform" it
> > > of exactly which records need to be cleaned up and what their real
> > > values should be?
> >
> > If the VM crashes the space management information (kept in
> > RAM only) is lost. To recreate it a scan of the whole file is
> > required.
> >
> > Best regards,
> >
> > Hans Bolinder, Erlang/OTP
> >

More information about the erlang-questions mailing list