<div dir="auto">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">mikpelinux@gmail.com</a>> skrev:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Tue, May 25, 2021 at 8:43 AM Nicolas Martyanoff <<a href="mailto:khaelin@gmail.com" target="_blank" rel="noreferrer">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>