What happens to your data when things go wrong.
Every result on this page comes from a test run against a published Semurg release, and names that release. A test that has not yet passed on a published release says results pending, and we claim nothing for it until it does.
On one node
A write is acknowledged only once it is stored. These tests break the node in the ways real machines break, then read every acknowledged write back.
| Test | What is done to the node | Release | Result |
|---|---|---|---|
| Process killed under load | 32 writers; the node is killed with kill -9 21 times in 137 seconds and restarted each time | r11.92 (14 Oct 2026) | Pass. No acknowledged write lost: 22.3 million read back. Writes still in flight at a kill are either there in full or absent, never damaged. Back to ready in 0.71 s (median). |
| Disk full | writes continue until the data volume fills | r11.92 (14 Oct 2026) | Pass. As the volume nears full, writes are refused by name (HTTP 507, "insufficient storage"); all 2,098,368 writes acknowledged before were read back. |
| Slow disk | the disk is throttled to a fraction of its speed under write load | r11.92 (14 Oct 2026) | Pass. Slower, never wrong: every acknowledged write read back at every throttle level. |
| Frozen process | the node is paused 5 times for 15 seconds under load | r11.92 (14 Oct 2026) | Pass. Every acknowledged write read back. 80 client calls timed out during the pauses; none of them was an acknowledged write that went missing. |
| Power cut | a sudden power loss, replayed at the block device (a datacenter drive with power-loss protection) | r11.92 (14 Oct 2026) | Not yet where we want it. On ext4, writes acknowledged in the last seconds before the cut can be lost: up to 14.6 s in one data shape (5 of 21 cuts beyond our 10 s bound) and up to 5.2 s in another. Anything acknowledged earlier survived every cut. A fix is in test (up to 4.0 s, not yet the default); the goal is zero. |
ACID, on one node
Atomicity
One write call is stored whole or not at all. Results pending: a dedicated test that kills the node in the middle of large calls and checks every call reads back whole or absent.
Consistency
A write that breaks a rule is refused by name, with the fix, and stores nothing. Measured so far in the disk-full test above (1,584 refusals, each named). Results pending: the full refusal set as one published test.
Isolation
One scope or user never sees another's data. Results pending: a published isolation test under concurrent writers.
Durability
The table above: an acknowledged write survives a killed process, a full disk, a slow disk and a frozen process. The power-cut window is the open item.
Across nodes
Running more than one node is meant to protect your data when a whole machine, disk or site is lost. The tests below decide whether it does. None has passed on a published release yet, so every result in this section is pending and this page claims nothing for more than one node.
| Fault | What must hold | Result |
|---|---|---|
| Network split between nodes, writes on both sides, then healed | no acknowledged write lost; every node agrees afterwards; a conflict is decided by a stated rule and the losing value stays readable | Results pending |
| A node killed under load, then restarted or replaced | no acknowledged write lost; reads keep answering from the other copy | Results pending |
| A node frozen, then resumed | no acknowledged write lost; the node catches up | Results pending |
| A disk lost on one node | its data comes back from another node | Results pending |
| Clocks out of step between nodes | the order of updates does not depend on any clock | Results pending |
| An independent analysis by an outside distributed-systems tester | the above, tested by someone who is not us | Not yet commissioned |
Said plainly: today a single node keeps what it acknowledged on its own disk, with the power-cut limit above. What more than one node adds is stated here only once the tests above pass on a published release.