Search code examples
chroniclechronicle-queue

file corruption or truncation on hard reset


When using ExcerptAppender over Chronicle Queue (append only log) is it guaranteed that only the end of file may be truncated in case of power loss i.e. all intermediate records are not corrupted? If so what implementation/filesystem/OS behaviour does this rely on?

I'm interested in linux/x64. Since this is over an mmap - my understanding is that the order of flushing of pages from page cache isn't defined and also the disk can reorder writes. Is it supposed to only be guaranteed for SSDs or a particular filesystem?


Solution

  • Queue relies on the OS flushing the data to disk asynchronously. The OS usually ensures data is pushed to disk within 30 seconds by default, however the pages written could be in any order, so while 99% of the last 30 seconds might be written there is a chance all of the last 30 seconds is unreadable. This time boundary isn't dependant on the choice of disk, rather configuration of the OS.

    The choice of disk alters the bust throughput sustainable, as well as how much data you can write before needing to archive or delete it.

    If you want reliable disk writes we recommend using replication to a 2nd or 3rd machine so that if the machine dies or the whole data centre is unavailable, you can continue operation. This uses Chronicle Queue Enterprise.