> ох уж эти мифы и легенды опеннета...
> у ext3 главные проблемы были совсем не в этом.Да не, все правильно он говорит. Тупило на уровне XFS если не хуже. Можно тоже было реально стирать файло по минуте. А одному хостингу я их ФС вообще просто в г@вно убил по перфомансу, при том случайно. Стало работать со скоростью практически флопика.
> Главная ее проблема (в ее исходном оригинальном виде а не в результате бэкпортов
> из 4) - сам журнал, без write barriers и без контроля целостности.
Ну как бы это нормальное дополнение к остальному "уровню технологий" этой шляпы. И без чексум, ага. Заметь - в EXT4 все ж сделали. Посмотрев на ZFS и btrfs. Но только для журнала, потому что там факапЪ фатальнее всего. К сожалению я нахожу чексумы региона данных весьма полезными, поэтому EXT4 стал для меня довольно бесполезным.
> И вот это был реальный п-ц. Тормозила она, собственно, тоже журналом,
> а не "айноды шерстит"
На файлах с кучей фрагментов (e.g. torrent) ожидать удаления файла можно было весьма долго. И такой перфоманс работы с метаданными воображение совсем не поражал. А у XFS и по сей день такое можно увидеть в примерно тех же условиях, без особых стараний.
> (и да, при удалении файла с кучей косвенных inodes журнал изрядно лагал,
> запись-то в него - синхронная, но точно так же и даже больше он лагал при его
> создании)
В случае какого-нибудь торента или БД фрагментация и дозаписи дефернуты по времени и это менее очевидно. А вот при стирании ты получишь весь поток шЫта концентрировано, оптом. И будешь минутами смотреть на потугу сделать unlink() в котором все отвисло на хз сколько.
> fsck там был тот же самый и по сей день остался, и идея журнала вообще-то в том
> что fsck нинюна (ой, если бы). экстентов вот не было, но они тогда не очень-то
> и были нужны.
Ага, только чот после их реализации ряд нагрузок втопили просто в разы. Если конечно на 200 меговый винч эпохи 386 ориентироваться, там, конечно, зачем тебе экстенты, куда ты их там...
