[erlang-questions] mnesia sync_transactions not fsynced?

[Håkan Mattsson]

For obvious reasons, the write cache in disk_log ought to be disabled
for the transaction log.

/Håkan

On Fri, Oct 28, 2011 at 9:18 AM, Dan Gudmundsson <dangud@REDACTED> wrote:
> Disk log cashes writes as well so you can loose many writes when
> halting the process.
>
> /Dan
>
> On Fri, Oct 28, 2011 at 1:05 AM, Jon Watte <jwatte@REDACTED> wrote:
>>
>>>
>>> runtest(N) ->
>>>    mnesia:sync_transaction(
>>>        fun () -> mnesia:write(testtab, #testrec{id = N}, write) end),
>>>    mnesia:sync_transaction(fun () -> mnesia:delete({testtab, N}) end),
>>>    runtest(N-1).
>>>
>>
>>
>> This code runs two separate transactions.  One to add a record, and one to
>> delete a record. If you bring down the node after the first one has
>> committed, but before the second one has committed, then you will see one
>> record when you start up again.
>> Are you claiming that if you run this from 100 through 0, and crash the node
>> at 10, you may see a record with the value 40 in the database? If that is
>> the case, then the cause is simply that all of the transactions from 39 .. 0
>> never wrote to disk before the crash. This can, roughly, be thought of as a
>> SQL database achieving some particular point in its binlogs, but nothing
>> beyond that point.
>> The observation here is that mnesia:sync_transaction(), under the conditions
>> observed, does not fulfill the "Durable" part of ACID transactions -- a
>> committed transaction (writing value 39, say) was observed by the system,
>> but after re-start, that point was not durable.
>> Whether mnesia:sync_transaction() "should be" durable is not something I'm
>> qualified to answer :-) However, reading the documentation, it certainly
>> *sounds* as if it should provide durability:
>>>
>>> This function waits until data have been committed and logged to disk (if
>>> disk is used) on every involved node before it returns
>>
>> Thus, assuming that you don't have a kernel/device-based write
>> cache/power-fail outage (but simply an Erlang process death outage), then I
>> would expect the last record seen on disk to be the last record observed in
>> the test function.
>>
>> Sincerely,
>> jw
>>
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>