Post #2085727

2025-12-10 18:18 UTC

The reason `fsync` exists in Unix is for applications to avoid calling it. Unix could have made filesystems sync automatically, but that would have a high cost, because it would end up doing a of needless work for temporary and intermediate data. Instead of having the filesystem abstraction convey the intent of data, Unix bubbles up the responsibility to call `fsync` to higher-level application code. In this design, tools like `sed` aren&#39;t meant to call `fsync`. They operate near the level of the filesystem abstraction and don&#39;t have the information they&#39;d need to decide when not to call it. A script might invoke `sed` a thousand times and then do a single `sync` at the end, avoiding much needless cost while still achieving the desired end result. In contrast, `vim` does call `fsync`. The thing that makes `vim` different is that it knows a tiny bit about where it sits with respect to a human being&#39;s intent. So the decision to use `fsync` isn&#39;t about not letting errors pass silently. It&#39;s about whether the code you&#39;re writing has a bigger-picture understanding of the data it&#39;s processing.

Replies (4)

@saikou@gts.chuuni.solutions 2025-12-10 19:10

@sunfish@hachyderm.io this reminded me of https://news.ycombinator.com/item?id=19119991 (yeah, yeah, hacker news) which has people talking about how fsync is very difficult to actually use correctly, especially in a database context

Open ##2553651
@zwarich@hachyderm.io 2025-12-10 20:45

@sunfish@hachyderm.io fsync() is such a bad API. Imagine if the only tool we had for memory consistency was membarrier().

Open ##2553652
@mikalai@privacysafe.social 2025-12-10 21:06

@sunfish@hachyderm.io Is it an example of non-trivial abstraction leaking. If one wants to have write that syncs always, well, it is a library to patch fs abstraction, where you want it.

Open ##2553653
@teajaygrey@snac.bsd.cafe 2026-01-07 10:59

That's, a perspective. Certainly one with which we have had to contend. It doesn't mean it was a wise choice. Contrast for example, Commodore Amiga's FFS, which would automatically sync the filesystem approximately every second. The computer was powered on and off via a power switch, at any time. No need to fsck the filesystem, ever. No need to "shut down" or "halt" or run any sort of magic script, just treat it like an appliance as simple as a toaster. Worked brilliantly. If you've ever had the misfortune of using an AT&T UNIX PC? If you flipped the power switch? It would trigger a shutdown script, and you'd be waiting there, for quite some time, as the system "gracefully" powered down. The UNIX Hater's Handbook, is largely forgotten, and predominantly written by Lisp Machine sorts, but there were other perspectives and implementations with regards to filesystems and how antiquated and broken UNIX seemed, even in the 1980s. Alas, we seem stuck in a "worse is better" 2026, and the saner alternatives? Are mostly not in active development anymore.

Open ##2553654