On Tue, Dec 24, 2024 at 3:54 AM Michael Tokarev <m...@tls.msk.ru> wrote: > > Hi! > > The no-unsafe-io workaround in dpkg was needed for 2005-era ext2fs > issues, where a power-cut in the middle of filesystem metadata > operation (which dpkg does a lot) might result in in unconsistent > filesystem state. This workaround slowed down dpkg operations > quite significantly (and has been criticised due to that a lot, > the difference is really significant). > > The workaround is to issue fsync() after almost every filesystem > operation, instead of after each transaction as dpkg did before. > > Once again: dpkg has always been doing "safe io", the workaround > was needed for ext2fs only, - it was the filesystem which was > broken, not dpkg. > > Today, doing an fsync() really hurts, - with SSDs/flash it reduces > the lifetime of the storage, for many modern filesystems it is a > costly operation which bloats the metadata tree significantly, > resulting in all further operations becomes inefficient.
Holy moly, is *this* why apt is sometimes slow to the point where you think you're going to die before the software upgrade finishes? :P I'm kidding obviously, but I have had upgrades that were unbelievably slow and there didn't seem to be much CPU activity to help me understand why. I bet this is it. > How about turning this option - force-unsafe-io - to on by default > in 2025? That would be a great present for 2025 New Year! :) I love this idea. Just in case there are some ext2 users still out there though, maybe dpkg could do its fsyncs intelligently, detecting any ext2 filesystems mounted on the system and issuing an fsync only after filesystem operations that affect an ext2 filesystem? > Thanks, > > /mjt >
