[erlang-questions] Mnesia doesn't report insertion errors when underlying DETS file is full?

[Ulf Wiger]

> On 23 May 2015, at 07:42, Kenneth Lakin <kennethlakin@REDACTED> wrote:
> 
> When the DETS table hits 2GB, mnesia:activity keeps
> on trucking: it doesn't throw or exit when called with either
> transaction, or async_dirty.
> 
> I would have expected mnesia:transaction to return {aborted, table_full}
> or something, rather than lying that my data was committed. Is this an
> unreasonable expectation? Did the Ubuntu or Debian folks mispackage
> Erlang in some way? Is this an oversight on the part of the OTP folks?

This is a known problem. Dets returns an error when the table is full, but this error cannot be handled by mnesia, since it occurs *after* commit - mnesia simply expects the backend store to work.

There are a number of ways to address the issue:

* Use mnesia_frag to fragment disc_only tables. This is no guarantee that you will avoid the issue, but by continuously monitoring the number of objects vs number of fragments, you can minimize the risk. I consider this a pretty ugly solution, but it has been used in commercial systems. One can of course also manually ‘fragment’ the data, but this has the same issues, and then some.

* Use disc_copies, ensure that you have a big enough box to keep all data in RAM. This has been used to great lengths by some commercial companies. The solution is not that bad, although eventually, you end up with some pretty ridiculous hardware, and pretty long startup times, since all data must be bulk-loaded into memory. One advantage is that reads and match operations become wicked fast.

* Fix dets to support larger data sets. Richard Carlsson once wrote a 64-bit dets version, but it has not been adopted by OTP. One could argue that the underlying dets design is unsuitable for very large data sets, e.g. due to its recovery semantics.

* Use an alternative backend. This has been done a few times, e.g. with ‘mnesiaex’ [1], but AFAIK, it is nowadays obsolete. Klarna has presented a similar approach, using the eleveldb backend [2], but has not (unless I missed it) made any recent announcement regarding status or availability of this solution.

* Use another database solution. Many projects do this. You will forfeit some of the unique characteristics of mnesia - in particular, the extremely close integration with the runtime environment - but obviously gain other things.

BR,
Ulf W

[1] https://www.openhub.net/p/mnesiaex
[2] https://erlangcentral.org/mnesia-backend-plugin-framework-and-a-leveldb-based-plugin/#.VWA08FmeDGc

Ulf Wiger, Co-founder & Developer Advocate, Feuerlabs Inc.
http://feuerlabs.com