LisPi on Nostr: <When my instance stops being broken I might replace this with a link to the earlier ...
<When my instance stops being broken I might replace this with a link to the earlier post>
The issue with data consistency *could* in theory by addressed by `btrfs`' `flushoncommit` if there was any guarantee that `write(2)` payloads didn't get split on their way to the page cache, that `write(2)` was atomic and that one only ever used `write(2)` with the full relevant data in a single call. There is no such thing.
`ZFS`' `recordsize` *might* address it if it indeed ensures nothing gets committed in a transaction that hasn't accumulated into such a block of writes. Assuming your use-case a has a strict fixed record size that fits in the `zfs_max_recordsize` limit.
Just make your software explicitly transactional chat, there are way too many layers of uncertainty and portability nightmares.
Published at
2026-09-21 19:55:32 UTCEvent JSON
{
"id": "42a5c2ddf10cd49b88a81926b0e650a954b699c578cfb8d5a116db27b5e6453c",
"pubkey": "8ab44a84fb757fea3c983e68a9bcc8e331fa49ed99cfcfd06a4499d542eae93c",
"created_at": 1790020532,
"kind": 1,
"tags": [
[
"content-warning",
"Some more thinking on filesystems and transactions"
],
[
"proxy",
"https://udongein.xyz/objects/f2905a2f-bc02-44a4-86b0-ccb60b9bd1c4",
"activitypub"
],
[
"L",
"pink.momostr"
],
[
"l",
"pink.momostr.activitypub:https://udongein.xyz/objects/f2905a2f-bc02-44a4-86b0-ccb60b9bd1c4",
"pink.momostr"
],
[
"-"
]
],
"content": "\u003cWhen my instance stops being broken I might replace this with a link to the earlier post\u003e\r\n\r\nThe issue with data consistency *could* in theory by addressed by `btrfs`' `flushoncommit` if there was any guarantee that `write(2)` payloads didn't get split on their way to the page cache, that `write(2)` was atomic and that one only ever used `write(2)` with the full relevant data in a single call. There is no such thing.\r\n\r\n`ZFS`' `recordsize` *might* address it if it indeed ensures nothing gets committed in a transaction that hasn't accumulated into such a block of writes. Assuming your use-case a has a strict fixed record size that fits in the `zfs_max_recordsize` limit.\r\n\r\nJust make your software explicitly transactional chat, there are way too many layers of uncertainty and portability nightmares.",
"sig": "fc0189cecb9c948ba7778f7b1f2c88b0d62209c9b1f9e698ea0628a38ad15fb8e2b0dd9bc7bab035a3b1f38fb11139741692ea769c9a7bdd0b56e4f2c467c726"
}