<div dir="ltr">The logic is spread out, but a starting point is where the actual commit is logged.<div><br></div><div><a href="https://github.com/erlang/otp/blob/master/lib/mnesia/src/mnesia_tm.erl#L284-L291">https://github.com/erlang/otp/blob/master/lib/mnesia/src/mnesia_tm.erl#L284-L291</a><br></div><div><br></div><div>But there are several different places where stuff happens. Check also the mnesia_tm:do_commit()</div><div>function: <a href="https://github.com/erlang/otp/blob/master/lib/mnesia/src/mnesia_tm.erl#L1781-L1797">https://github.com/erlang/otp/blob/master/lib/mnesia/src/mnesia_tm.erl#L1781-L1797</a></div><div><br></div><div>and the mnesia_dumper.erl module (which reads the commit log and disperses the data into the</div><div>different tables, both at startup, and periodically, to avoid having the commit log grow too large.)</div><div><br></div><div>BR,</div><div>Ulf</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 27, 2021 at 4:31 PM Frank Muller <<a href="mailto:frank.muller.erl@gmail.com">frank.muller.erl@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">Thanks for the info Ulf. </div><div dir="auto"><br></div><div dir="auto">Could you please point me to the WAL source code?</div><div dir="auto">Curious to know how it’s implemented.  </div><div><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><br>Mnesia has a WAL (Write-Ahead Log), in which it writes data safely. It then writes to dets (if that's the chosen table type).<div><br></div><div>At startup, dets files are repaired if they don't appear to have been properly closed. Then the transaction log is applied, making sure that the database is consistent.</div><div><br></div><div>Repairs of dets files have been known to take time in the past, but I think OTP has optimized it, Klarna optimized the mnesia end of it, and both computers and disks are insanely faster now.</div><div><br></div><div>I'd say that the most glaring issue with disc_only_copies in mnesia is not even the 2 GB limit, but the fact that if you get there, dets will simply discard the update, and mnesia won't even notice. That is, your application must ensure that you never exceed the dets limit.</div><div><br></div><div>Most people use disc_copies for persistence, since they have better performance and better reliability than disc_only_copies. The downside is that the table will also fit in RAM. A different approach would be to use a backend plugin. There are three alternatives to choose from, as far as I know: leveldb, leveled, and rocksdb. There may be issues building leveldb on newer OTP versions. Leveled is (almost) entirely erlang-based, so it wins hands-down on build time. Rocksdb should be the fastest, although the difference isn't dramatic.</div><div><br></div><div>BR,</div><div>Ulf W</div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 27, 2021 at 8:52 AM Frank Muller <<a href="mailto:frank.muller.erl@gmail.com" target="_blank">frank.muller.erl@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">How about Mnesia and persistence to disk?</div><div><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><br>It's always tricky with open files during some abrupt crashes. OS-level file system caching means that not all written data may have been physically written to disk.<div dir="auto"><br></div><div dir="auto">To detect this, dets has a flag indicating whether the file was properly closed. As I understand it, the 'auto-save' does the same thing as when the file is closed, except the file stays open.</div><div dir="auto"><br></div><div dir="auto">BR,</div><div dir="auto">Ulf W</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Den ons 26 maj 2021 23:10Mikael Pettersson <<a href="mailto:mikpelinux@gmail.com" target="_blank">mikpelinux@gmail.com</a>> skrev:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, May 25, 2021 at 8:43 AM Nicolas Martyanoff <<a href="mailto:khaelin@gmail.com" rel="noreferrer" target="_blank">khaelin@gmail.com</a>> wrote:<br>
> I was hoping to use DETS as a local persistent buffer in case data<br>
> cannot be written to a remote database, but it seems impossible to<br>
> guarantee that every entry is being sync-ed to disk.<br>
<br>
I'm not too familiar with the internals of DETS, but basically data<br>
goes straight to/from disk while meta-data about allocated and free<br>
areas of the file are cached in memory. I don't know if writes are<br>
sync or not. In our experience, DETS files are somewhat fragile, plus<br>
they have a hard 2GB size limitation which made them extremely awkward<br>
for our use case (large mnesia tables). That's part of the reason we<br>
migrated most of our mnesia tables to eleveldb.<br>
<br>
If I had to have a standalone (not mnesia) local persistent store I'd<br>
probably go with eleveldb (or one of its spinoffs) if I needed lookups<br>
by key, or a disk_log if I just needed a FIFO buffer. disk_log allows<br>
you to choose how sync or async your writes are. _I_ wouldn't use<br>
DETS.<br>
</blockquote></div>
</blockquote></div></div>
</blockquote></div>
</blockquote></div></div>
</blockquote></div>