Join Nostr
2026-09-21 19:55:32 UTC

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.