История изменений

Да в dpkg куча легаси и неудобных вещей, один только fsync() на все файлы при установке пакетов дделается лишь потому, что dpkg разрабатывался до изобретения журналируемых файловых систем, и за ~25 лет никто и не исправил его поведение.

Что? Без fsync() не гарантируется завершённость записи содержимого файлов. Те же ext4 и btrfs страдали потерей данных из-за механизма отложенной аллокации. Сейчас как минимум в первой есть несколько эвристик, которые запускают запись данных при некоторых типичных условиях (например, если rename() заменяет существующий файл, то происходит запись существующих отложенных аллокаций), но сами разработчики ext4 в лице Theodore Tso говорят, что эти механизмы существуют лишь для неправильно работающих приложений, что полагаться на них нельзя, и что приложения должны вызывать fsync().

И вообще, перекладывание здесь ответственности на dpkg — это с больной головы на здоровую. Проблема-то на самом деле в тормозной ext4, которая при вызове fsync(fd) синхронизирует не только данные файла, соответствующего fd, но и чуть ли не всех остальных файлов в системе, потому что журнал работает на уровне блоков, а не файлов. fast_commit должен помогать в этом случае.

Да в dpkg куча легаси и неудобных вещей, один только fsync() на все файлы при установке пакетов дделается лишь потому, что dpkg разрабатывался до изобретения журналируемых файловых систем, и за ~25 лет никто и не исправил его поведение.

Что? Без fsync() не гарантируется завершённость записи содержимого файлов. Те же ext4 и btrfs страдали потерей данных из-за механизма отложенной аллокации. Сейчас как минимум в первой есть несколько эвристик, которые запускают запись данных при некоторых типичных условиях (например, если rename() заменяет существующий файл, то происходит запись существующих отложенных аллокаций), но сами разработчики ext4 в лице Theodore Tso говорят, что эти механизмы существуют лишь для неправильно работающих приложений, что полагаться на них нельзя, и что приложения должны вызывать fsync().