>>Ибо динамическую аллокацию инод оно не умеет.
> С помощью бубна и LVM это можно поправить.

Получится хорошая иллюстрация на тему "given enough thrust pigs fly just fine" имхо.

> Но вообще-то Ари для аллокации инод было написано.

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

> от утилиты, т.к риск потери информации оказался слишком большим, особенно на
> фрагментированной фс.

Одна из проблем in-place дизайнов состоит в том что практически любой факап...
1) Может быть достаточно фатален, если лезет достаточно глубоко в дебри.
2) Многие продвинутые операции очень стремные.
3) Отыграть что либо взад - крайне сложно. Потому что изначально это не было предусмотрено совсем, старое состояние может быть уже разрушено.

В этом смысле cow где сперва делается копия (возможно, с изменением схемы хранения и проч) а потом на нее "перевешивается указатель" если все прокатило - в целом менее дурацкая операция, к тому же как правило прощающая случай "не прокатило". У меня как-то слетело питание при рестрайпе RAID на btrfs в другую схему. Ну, перезагрузился - да запустил заново, оно и доделалось. Можно вообще не рестрайпить явно а только дефолт сменить, новые записи будут в новой схеме. И только. А что было бы на более классическом дизайне при таком фортеле я даже представить не берусь. Фанаты сратисов и LVM могут посмотреть что там, если не лениво сетапить операцию - при том что оно потенциально может сдохнуть, вероятно, если не повезет.