>[оверквотинг удален]
> у ext3 главные проблемы были совсем не в этом. Главная ее проблема
> (в ее исходном оригинальном виде а не в результате бэкпортов из
> 4) - сам журнал, без write barriers и без контроля целостности.
> И вот это был реальный п-ц. Тормозила она, собственно, тоже журналом,
> а не "айноды шерстит" (и да, при удалении файла с кучей
> косвенных inodes журнал изрядно лагал, запись-то в него - синхронная, но
> точно так же и даже больше он лагал при его создании)
> fsck там был тот же самый и по сей день остался, и
> идея журнала вообще-то в том что fsck нинюна (ой, если бы).
> экстентов вот не было, но они тогда не очень-то и были нужны. Ну уж, мифы, скорее наблюдения. На какоим нибудь не самом быстром процессоре в сидбоксе на не самом быстром жестком диске удаление крупного (на многие гигабайты) торрента могло подвесить transmission-daemon настолько что он переставал отвечать на RPC запросы.
В EXT4 на сколько я понимаю эту проблему решили неспешным удалением в фоне, даже оставшихся в насление битмаповых файлов. С экстентами опять же все стало проще.
Ну а FSCK все же ext4 проверяет наааамного быстрее, если только ФС не забита под завязку.
И да, конечно проблемы с медленным удалением не были главной АРХИТЕКТУРНОЙ проблемой, но наглядно бесили на пользовательском уровне. Главными проблемами под капотом были, да, журнал, сама устаревшая система размещения файлов, фрагментация и вот большую часть всего этого решали именно внедрением экстентов + B-tree и кучей мелких, но метких оптимизаций.
Даже официальные инструкции поэтому не рекомендуют апгрейдить ext3 до 4, вместо этого предлагая полностью пересоздавать ФС с нуля - просто чтобы избавиться от не-экстентов.
