On Thu, Dec 26, 2024 at 09:23:36PM +0900, Simon Richter wrote:
My feeling is that this is becoming less and less relevant though, because it does not matter with SSDs.
To summarize: this thread was started with a mistaken belief that the current behavior is only important on ext2. In reality the "excessive" fsync's are the correct behavior to guarantee atomic replacement of files. You can skip all that and in 99.9% of cases you'll be fine, but I've seen what happens in the last .1% if the machine dies at just the wrong time--and it isn't pretty. In certain situations, with certain filesystems, you can rely on implicit behaviors which will mitigate issues, but that will fail in other situations on other filesystems without the same implicit guarantees. The right way to get better performance is to get a reliable SSD or NVRAM cache. If you have a slow disk there are options you can use which will make things noticeably faster, and you will get to keep all the pieces if the system blows up while you're using those options. Each person should make their own decision about whether they want that, and the out-of-box default should be the most reliable option.
Further reading: look at the auto_da_alloc option in ext4. Note that it says that doing the rename without the sync is wrong, but there's now a heuristic in ext4 that tries to insert an implicit sync when that anti-pattern is used (because so much data got eaten when people did the wrong thing). By leaning on that band-aid dpkg might get away with skipping the sync, but doing so would require assuming a filesystem for which that implicit guarantee is available. If you're on a different filesystem or a different kernel all bets would be off. I don't know how much difference skipping the fsync's makes these days if they get done implicitly.
