>как говно мамонта EXT1 начала 1990-хВсе так. Только к EXT4 старикана так перепилили что оригинал и не узнать. Тут вам и экстенты, и хешированные директории, и отложенное выделение. В общем все как у большинства иных подобных ФС типа XFS, JFS, etc. Не свежак и не последний писк, но и параметры не позорные. Весьма резвая такая ФС. И отлаженная временем.
> — встречаются куда чаще
Угадаете с трех раз почему? Наверное секрет в том что с хешированными дирами и экстентами - параметры EXT4 даже похожи на что-то приличное.
>отрихтованной и доведённой до ума стандартной юниксовой ФС в 2005 году UFS2.
Что-то никому этот ваш UFS2 как файловая система толком не нужен. Может быть, это потому что дисковые структуры недалеко ушли от "говна мамонта", со всеми вытекающими, как то неважненькая производительность на ряде нагрузок?
>>Во первых, это умеют другие слои.
>Во-первых, эта отговорка уже не катит.
Это зависит от того шашечки или ехать. Если цель разрулить задачу - это одно. Если подрочить на академически правильное решение - другое.
>Пока ты склеиваешь необходимые слои между собой и получаешь рабочий снапшот,
>может пройти очень много времени, что непозволительно для продакшена.
А мужики то не знают. Странно. Наверное iZEN им не попадался. Упущеньице.
>К тому же, снапшоты линуксовых ФС нужно делать на неживой-отмонтированной ФС.
Откуда это следует?
>И, да, скорость записи на раздел со снапшотом в линуксе почему-то проваливается
>в разы по сравнению с разделом без снапшота. Почему так?
Вам анонимаус объяснял вроде? Это было безрезультатно? При том он объяснял что однозначно выигрышной стратегии нет, IIRC.
>Ведь другие нормальные ФС, поддерживающие снимки внутри себя, не страдают от этого дефекта.
Да, конечно, btrfs какойнить так работает что снимки - просто его логика работы. Это впрочем не означает что у него других проблем не будет.
>Вроде и нет больше _современных_универсальных_ ФС в Linux, годных к продакшену. Или
>я не прав?
XFS тот же - он может и не суперуниверсал, но на ряде применений (большие файлы, etc) очень так ничего. И на несколько дисков размазывается хорошо, чем ext4 похвастать не может.
>Устойчивую к сбоям UFS2, не нуждающуюся для защиты метаданных в журнале ты
>назвал "кондовыми граблями".
Про ее устойчивость к сбоям вам имхо доступно рассказали в соседнем посте. Вот у настоящих CoW файловых систем с недеструктивной записью - там да, устойчивость к сбоям есть. На уровне устройства ФС, так что и файлы и метаданные можно вернуть к какому-то предсказуемому состоянию, исключив ситуации "запись обломалась на середине - файл наполовину перезаписан".
>Ну-ну. Посмотрел бы я на надёжность современных линуксовых ФС, если ВНЕЗАПНО
>выключить электричество, а у них не окажется журнала.
И даже с журналом - гарантируется непротиворечивое состояние журнала и структур ФС. А вот что будет с файлами - вопрос номер два. Гарантию атомарности записи данных + метаданных в классических ФС дает полное журналирование. А оно тормозное из-за двойной операции записи.
>Журнал необходим для быстрого восстановления после сбоев. Во время нормальной работы он
>отнимает на себя достаточно заметную долю ресурсов как дисковой подсистемы,
Если журналятся только метаданные - то не отнимает. Обычно все соглашаются на такой вот компромисс. В итоге тормоза могут возникать только при metadata-intensive workload'ах. А это довольно нишевые и не частые случаи (именно поэтому кстати вырубить всякие там времена доступа - отличная идея).
>так и центрального процессора. Лучше отказаться от журнала вообще и обеспечить механизм
>внутренней согласованности жизненно важных структур,
Насколько я понял спич по любезно приведенной в соседнем сообщении ссылке - механизм soft-updates в UFS2 не обещает что если я записывал файл и если все фигакнулось в момент записи то у меня будет или старый файл, или новый. А не нечто, наполовину старое и наполовину новое, не факт что юзабельное вообще.
>чем делать подпорки и костыли, тюнинг журналирования.
Строго говоря - я не без причин полагаю что будущее за ФС с недеструктивной записью, т.е. CoW-подобными файловыми системами. У них конечно своих грабель навалом, однако их плюсы в виде недеструктивности и возможности хранить более 1 версии файла - явно перевешивают.
>>Ну уж наверное не потому что они дураки, правда? :)
>Правда. Потому что экстенты на больших объёмах обслуживаемых данных эффективнее
>простых битовых карт (сканирование и определение непрерывных цепочек блоков
>тупо быстрее идёт). Но только на больших объёмах.
А объемы данных растут, если вы не заметили. Ноутбячный винч размером полпачки сигарет в терабайт никого уже не удивляет.
