Re: A 2025 NewYear present: make dpkg --force-unsafe-io the default?
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.
Reply to: