>> меры, обновление размером 1Гб устанавливалось 3 (ТРИ часа) на SSD RAID0.
> Само по себе такое возможно и в нормальном виде - если там
> тысячи файлов. А кто сказал что SSD быстро полностью скидывают буфера
> на запись? Циферки в бенчах эти господа указывают без сброса буферов
> после каждой команды. Более того - SSD явно желают чтобы их
> информировали о намерении снять питание и все такое - и логгят
> если вы это не сделали. И с таким логом хрен чего
> предъявите производителю за потерю данных, покажут 5-й шрифт в доках и
> пробурчат "сами виноваты".

Это понятно. Другой дело, что на том же железе, на той же ФС, за то же время устанавливались те же пакеты в Gentoo, собираясь из исходников.

> Еще кстати стоимость разных позиксных вызовов у разных ФС довольно разная.

Так точно. Устанавливал эту ROSA Fresh на ZFS, где синхронизация отключается в свойствах тома https://github.com/zfsonlinux/zfs/blob/zfs-0.8-release/man/m...
потому проблему не видел до смены ФС.

> Возможно
> у разработчика конфигурация была другой.

У директора в то время вообще была MacOS. Разработчики (коих тогда было трое, включая "QA") признали проблему, как видно по ссылке на форум и из анонса R11 https://www.opennet.ru/opennews/art.shtml?num=50325 (здесь, кстати, исправили оригинальное fsync() на корректное fdatasync() -- то есть составитель "инженер" РОСА откровенно плавает в вопросе).

>> Ребилд базы данных RPM: rpm --rebuilddb - Mageia=5 сек - ROSA=4 мин. 45 сек
> ...
>> тупо скопировали макрос-костыль, приводящий к регрессии в urpmi, на чём и успокоились.
> А, ну вот и объяснение факапища. Единственное чего я не понял -
> чего можно с fdatasync делать при поиске?!

Перестраивать индексы БД для ускорения повторного поиска. При чём делать это каждый раз (с чем и следовало разбираться, а безусловное отключение fdatasync и не является решением, лишь заметает грязь под ковёр).