News for hackers. Stuff that matters.
Re:Async I/O on Linux in databases by nephalegm on Sunday July 20, 2025 @06:27AM (#44623693)
Reading through the article it’s explained in the recovery process. He reads the intent log entries and the completion entries and only applies them if they both exist.

So there is no guarantee that operations are committed by virtue of not being acknowledged to the application (asynchronous) the recovery replay will be consistent.

I could see it would be problematic for any data where the order of operations is important, but that’s the trade off for performance. This does seem to be an improvement to ensure asynchronous IO will always result in a consistent recovery.

Re:Async I/O on Linux in databases by ori_b on Sunday July 20, 2025 @08:55AM (#44624775)
There's not even a guarantee that the intent log flushes to disk before the completion log. You can get completions entries in the completion log that were lost in the intent log. So, no, there's no guarantee of consistent recovery.

You'd be better off with a single log.

Re:Async I/O on Linux in databases by lmeyerov on Sunday July 20, 2025 @11:01AM (#44625821)
I think he says he checks for both

It's interesting as a weaker safety guarantee. He is guaranteeing write integrity, so valid WAL view on restart by throwing out mismatching writes. But from an outside observation, premature signaling of completion, which would mean data loss as a client may have moved on without retries due to thinking the data was safely saved. (I was a bit confused in the completion meaning around this, so not confident.)

We hit some similar scenarios in Graphistry where we treat recieving server disk/RAM during browser uploads as writethrough caches in front of our cloud storage persistence tiers. The choice of when to signal success to the uploader is funny -- disk/RAM vs cloud storage -- and timing difference is fairly observable to the web user.

Re:Async I/O on Linux in databases by toast0 on Sunday July 20, 2025 @11:01AM (#44625820)
There's no guarantee of ordering of writes within the two logs either.

This seems nightmarish to recover from.