Files
turso/core
Pekka Enberg 6d80d862ee Merge 'io_uring: prevent out of order operations that could interfere with durability' from Preston Thorpe
closes #1419
When submitting a `pwritev` for flushing dirty pages, in the case that
it's a commit frame, we use a new completion type which tells io_uring
to add a flag, which ensures the following:
1. If any operation in the chain fails, subsequent operations get
cancelled with -ECANCELED
2. All operations in the chain complete in order
If there is an ongoing chain of `IO_LINK`, it ends at the `fsync`
barrier, and ensures everything submitted before it has completed.
for 99% of the cases, the syscall that immediately proceeds the
`pwritev` is going to be the fsync, but just in case, this
implementation links everything that comes between the final commit
`pwritev` and the next `fsync`
In the event that we get a partial write, if it was linked, then we
submit an additional fsync after the partial write completes, with an
`IO_DRAIN` flag after forcing a `submit`, which will mean durability is
maintained, as that fsync will flush/drain everything in the squeue
before submission.
The other option in the event of partial writes on commit frames/linked
writes is to error.. not sure which is the right move here. I guess it's
possible that since the fsync completion fired, than the commit could be
over without us being durable ondisk. So maybe it's an assertion
instead? Thoughts?

Closes #2909
2025-09-05 08:34:35 +03:00
..
2025-09-02 18:25:20 +07:00
2025-08-21 14:45:00 -04:00
2025-06-23 19:52:13 +01:00
2025-06-30 10:01:03 +03:00
2025-08-15 17:08:53 -04:00
2025-01-28 14:55:38 -05:00
2025-09-01 11:11:25 -03:00
2025-06-23 19:52:13 +01:00
2025-08-30 03:10:39 -03:00
2025-01-28 14:55:38 -05:00
2025-09-04 21:09:12 +03:00
2025-06-23 19:52:13 +01:00
2025-09-04 13:04:53 +07:00
2025-06-30 09:54:13 +03:00
2025-08-21 15:23:59 -03:00