>POSIX позволяет пустую реализацию fsync(). Пример: MacOSX.

Я сердечно поздравляю юзеров макоси с этим фактом.Не думаю что он их напрягает.Если уж им не в облом покупать втридорога только "одобренное свыше" железо (освященное богами, мля), не смущает DRM и ограничилово - то уж на целостность данных таким юзерам и вовсе насрать.Свое гей-порно они заново перекачают из интернета а ничего ценней там у них все-равно нету.

>Если у вас SSD или ноут или смартфон, то в ваших интересах
>не позволять приложениям дёргать fsync() попусту чтобы не палить флешку или
>разряжать батарею впустую.

А вы представляете себе слет конфигов на смарте вообще?Юзер не просто кардинально влопается и будет зол, сделав антирекламу.Он потащится в сервис и принесет вагон убытков.

Более того - в смартах флеш прицеплен напрямую к процу и ФС обязана сама озаботиться его wear leveling'ом, иначе он очень быстро протрется в некоторых областях.Для этого сделаны специальные ФС и уровни трансляции.Они стараются выравнивать операции на erase block, используют свойства физики флеша и так далее.Как пример - JFFS2, UBIFS и прочие.Они и журналят с поправкой на природу носителя.

Никому в здравом уме не приходит в голову юзать обычную ФС в смартфоне.И это правильно.Почему - см.выше.

А SSD - простите у него свой контроллер который wear leveling'ом занимается и софту и ОС строго говоря не видно во что по факту трансформируется тот или иной системный вызов.В принципе delayed allocation может подыграть но - в основном при очень специальной организации, когда записи пытаются выравняться на границы erase block-ов.Только учтя что в SSD реальная геометрия флеша скрыта его контроллером, драйвера ФС и ОС могут только гадать, попало ли выравнивание в цель или нет.В общем то если такое инфо не скрывать, драйвера ФС могли бы осмысленнее тюнить свое поведение под геометрию накопителя.