Сравнение производительности файловых систем или Reiser4 наносит ответный удар.

Не знаю как там насчет скорости и прочих параметров, но если железо битое, то ФС не имеет значения. Проверил на себе - 4 падения ФС за 2 недели благодаря посыпавшемуся венику. Причем падал как рейзер, так и ext3. Правда, последний имел наименьшие повреждения. А если учесть еще и то, что ни reiser4, ни ext4 в production ядрах нет, то это все фигня.

Я не понял... ext2 делает reiser3 ? (ну кроме операции удалить все)

>А если учесть еще и то, что ни reiser4, ни ext4 в production ядрах нет, то это все фигня.

ext4 идёт в mainline ядре.

Ганс сидит в КПЗ (по-нашему), дело передано в суд (раньше были только предварительные слушания). Адвокат думает, что в ближайшее время Ганс сядет уже по-настоящему, но надежды не теряет.

У меня распаковка иходников ядра линуска на reiser4 (defaluts) занимает в ~1.5 раза меньше времени, чем на ext3 (noatime), c учётом sync: разница в основном из-за разного времени сброса дисковых буферов, а это чистый io-load, лишних 20% CPU ради этого мне не жалко :)

ИМХО, ntfs-3g вообще нелогично включать в сравнение, потому что она работает поверх FUSE.

О корректности предоставленных результатов, конечно же, необходимо судить только анонимусам на ЛОРе

>As you can see, REISER4 is a truly remarkable filesystem.

>This is the real reason that REISER4 has not been included in the Linux kernel.

>This is the real reason that Hans Reiser languishes in an Oakland prison cell at this time.

бгг

> О корректности предоставленных результатов, конечно же, необходимо судить только анонимусам на ЛОРе

угу, ждем официального заявления сообщества анонимных аналитиков ЛОРа. по теме - есть у меня некое подсознательное неприятие reiserFS, связанное с 2-х кратными потерями важных данных в прошлом. а вот ext3, в отличие от, себя никогда плохо не вел.

На производительность (+-10%) мне всё равно, но рейзер3 у меня на нормальном винте как-то раз осыпался, причём капитально, а ехт3 я ставил на винт с битыми секторами, и он тянет это до сих пор.

Reiser4 уже который месяц не может пройти тестов на включение в ядро. Кому нафиг сплющилась эта производительность? Уж лучше медленне да с данными, чем на ракете в /dev/vagina

Сходил по ссылке. Графиков нет. Низачот.

>угу, ждем официального заявления сообщества анонимных аналитиков ЛОРа. по теме - есть у меня некое подсознательное неприятие reiserFS, связанное с 2-х кратными потерями важных данных в прошлом. а вот ext3, в отличие от, себя никогда плохо не вел. isden * (*) (06.04.2007 12:53:18)

Было и у меня такое на рейзере.... После банального отключения электричества... Так что мой выбор - только ext3! А если Линус включит в ядро, то и ext4...

По ссылке непонятки какие-то, глубоко не лез, но у автора в delete all xfs проиграла ext2/3 . То ли файлов мало, то ли файлы маленькие.. мне в это не верится.

У мну была ситуация, когда в каталоге лежало оболее(возможно гораздо более) 100 000 файлов. Так вот, тест простой - надо зайти в mc в этот каталог. На ext3 нужно ждать списка файлов минут десять наверное, может больше, сейчас не помню. после переезда на xfs - меньше минуты. Так же обстоит дело в удалением. ntfs вообще тугая в этих делах, было около 40Гб этих файлов, когда мы сменили винду на линукс. ntfs удалял эти 40Гб оочень долго(часов 6 наверное). Недавно при переезде удалял с xfs около 400Гб - часов 8 примерно. ЗЫ. Рейзер на таких задачах не пробовал (он позиционируется для маленьких файлов), но вот сравнение ext с xfs по моему явно некоректное(или ситуация сильно "плохой" для xfs попалась). В общем, к результатам я бы относился с осторожностью.. если кто возьмётся разобрать полёты и прокоментировать, плиз киньте ссылку куда нить..(можно в толксы).

попробуй jfs, она пошустрее на куче файлов (от 100 тысяч разного размера, на 500 тысячах она xfs делала заметно ;) )

Автор не проверил random write внутри файлов на reiserfs4 + compression. В этом случае Reiser был бы раз в дцать медленнее, чем остальные ФС. Т.е. использование компрессии и БД - верная смерть для сервера.

Кстати, приятно видеть, что ext4 значительно улучшена по сравнению с ext3.

> Я не понял... ext2 делает reiser3 ?

ext2 - это ФС _без_ журналирования. ;-)

>По ссылке непонятки какие-то, глубоко не лез, но у автора в delete all xfs проиграла ext2/3 . То ли файлов мало, то ли файлы маленькие.. мне в это не верится.

В bonnie++ тесте удаление у xfs быстрее, чем ext* (940 vs 770 файлов в секунду).

reiser3/4/4 --> reiser 3.4/4

>Автор не проверил random write внутри файлов на reiserfs4 + compression. В этом случае Reiser был бы раз в дцать медленнее, чем остальные ФС. Т.е. использование компрессии и БД - верная смерть для сервера.

Показал просто скорость случайного доступа к файлу - reiser4 с компрессией в 15 раз быстрее, без нее - на 5% медленее ext3.

>Кстати, приятно видеть, что ext4 значительно улучшена по сравнению с ext3.

Только тем, что добавили extents, по всем остальным параметрам та же самая ext3. И плюс расширили максимальные размеры до 48 бит.

Мда? спасибо, учту. Попробую при случае.

Reiser4 с компрессией начнет _очень_ сильно сливать на архивах с картинками, фильмами и уже запаковынными или плохокомпрессируемыми данными.

xfs, reiser - отрубало электричство, ресетилась машина, отваливалось питание от хдд и снова втыкалось - всё работает...

Кстати xfs со временем на забитом доверху разделе стала притормаживать. Особенно иногда удалять медленно очень стало (большие файлы)

>использование компрессии и БД - верная смерть для сервера.

чем больше выигрываешь в cpu, тем меньше выигрываешь в io, чем больше будет греться проц - тем меньше винт. у тебя всегда есть выбор.

>> Я не понял... ext2 делает reiser3 ?

> ext2 - это ФС _без_ журналирования. ;-)

пофиг. с ext3 та же ситуация.

Угу. "Спасибо, я лучше на травке посижу" Может у меня кривые руки, но с ядрами старше 2.6.18 вечно какие-то проблемы. Особенно при suspend2disk (на ноуте без него никак).

> Угу. "Спасибо, я лучше на травке посижу" Может у меня кривые руки, но с ядрами старше 2.6.18 вечно какие-то проблемы. Особенно при suspend2disk (на ноуте без него никак).

hibernate не хочет делаться если оставить на паузе mplayer. Ноут выключается только power'ом, при этом сигнатура в своп не пишется и загрузка происходит с "чистого" листа.

hibernate-ram вообще перестал работать - останавливал почти все демоны, не запускал "иксы" - не работает. Ноут отправляется в спячку, но проснуться уже не может. ТОлько ребут спасает.

Прошу прощения, что мимо топика.

Честно говоря, подобные статьи/обсуждения заставляют меня задумываться о бренности рассудка...

Почему-то _все_ подобные пузомерки исходят из мысли о некой универсальности файловых систем -- но это ж только для Оффтопика справедливо (ибо там просто выбора нет)!

ReiserFS выигрывает при большом числе мелких файлов (и соответствующих тестов) -- факт, поскольку в ней дерево сидит. ext2/3/4 надежнее -- личный опыт (взгляните, впрочем, на исходники -- думаю, после этого веры в Reiserfs поубавится). Показателен пример xfs -- универсальной файлухи опять не получилось, она выигрывает только при параллельном чтении/записи _очень_ больших файлов (иногда в разы, BTW!) и сливает той же Reiserfs на примитивном доступе к мелким файлам (тоже в разы).

>Ганс сидит в КПЗ (по-нашему), дело передано в суд (раньше были >только предварительные слушания). Адвокат думает, что в ближайшее >время Ганс сядет уже по-настоящему, но надежды не теряет.

А за что его посадили?

Насчет reiser могу сказать что ни разу не падала, после резета, отключения эл-ва и т.п. данные ни разу не потерялись.

Упорно ставил ext3, решил попробовать. После отключений и резетов терялись файлы.

года 2,5 стоит рейзер и никаких проблем... :-)

reiserfs3, notail, уже почти 3 года всё нормально. Хотя не спорю, на ядрах 2.6.3-2.6.5 были проблемы - после отключения электричества некоторые файлы забивались мусором. Но после 2.6.12 такого не наблюдается.

Еще никто особенно не обращает внимания, что тезис "PC hardware sucks" в целом учитывает только Ext3 (4). То, что XFS или Raiser оставались целыми после падений или отключения электричества говорит о том, что они в этот момент не были нагружены.

>Еще никто особенно не обращает внимания, что тезис "PC hardware sucks" в целом учитывает только Ext3 (4). То, что XFS или Raiser оставались целыми после падений или отключения электричества говорит о том, что они в этот момент не были нагружены.

Скорее никто из архитекторов файловой системы об этом не задумывался. Про XFS сразу ясно - SGI железо не чета PC, но Reiser создавался для PC, но о кривости железа не сильно думали.

>reiser3/4/4 --> reiser 3.4/4

ясно ж написано: reiser3 / 4 / 4 with compression

Другая сторона медали: специально высовывал шнур питания раз 5 при sync-е достаточно больших (~300Мб) объёмов данных в момент где-то на 50% от времени завершения. Последующая проверка ошибок не выявляла, но на reiser4 часть файлов всё-таки записывалась (в пределах тех 50%), на ext3 было пусто. Субъективно, ext3/4 ведут себя как деревянные и генерируют больше IO-запросов.

fossil не мерял ... незочот !

Не все так плохо Артем.

Обоснование:
1. На сколько я помню компрессия делается в момент флаша то есть в page cache-е данные несжаты и значит есть вероятность (большая) что ничего осбобенного делать не надо будет даже в random writes случае;

2. Если первый пункт не стрельнет и если CPU свободен то время потраченное на декомпресию будет намного меньше времени потраченного на IO + всякие там переключения контеста и др.;

3. Вроде как он умеет найти нужный блок даже если файл сжат, то есть не надо вычитывать и декомпресировать всю портянку, достаточно зачитать несколько блоков.

Звучит логично? :)

не знаю, что это было..... Но неприятно.

В ext3 есть 3 варианта журналирования, так что это настраивается под нужды. Вот попробуй запустить распаковку исходника ядра в одно место и перенос другой копии куда-то на raiser (ну или просто 2 помойки мелких файолов копировать и стирать в разных направлениях). У меня на таком слетало безвозвратно после сбоя питания.

> Упорно ставил ext3, решил попробовать. После отключений и резетов терялись файлы. года 2,5 стоит рейзер и никаких проблем... :-) antosxz (*) (06.04.2007 15:20:27)

файлы терялись, бывало.. но весь же раздел! а на рейзере - раздел упал. :-(

А какую великий алл посоветует ФС для максимально быстрого произвольного доступа (чтение) к одному ну очень гигантскому файлу (сотня и более гигов). Никаких других требований кроме скорости чтения из произвольных мест нет. Сейчас на XFS, но может что получше есть?

> А за что его посадили?

По подозрению в убийстве.

>А какую великий алл посоветует ФС для максимально быстрого произвольного доступа (чтение) к одному ну очень гигантскому файлу (сотня и более гигов). Никаких других требований кроме скорости чтения из произвольных мест нет. Сейчас на XFS, но может что получше есть?

По слухам googlefs как раз и есть чтение/запись в огромные файлы.

O_DIRECT может помочь в собственном приложении.

А из файловых систем общего назначения, imho, xfs как раз для таких задач.

кто нибудь ext4 пользуется ? насколько там устоялся формат, не будет ли менятся в будущем ? хочу винт файлопомойки на 750Г под ext4 отформатить интересует не придется ли в будущем переформатить...

>Кстати xfs со временем на забитом доверху разделе стала притормаживать. Особенно иногда удалять медленно очень стало (большие файлы)

Какой дистро? В некоторых дистрах типа юубубунты и рхель с чего то патчиками на ядро отрубают по дефолту все сервисы XFS кроме формального xfs журналирования от чего его заедает фрагментация.

Весьма хорошо подметили что фс штуки не универсальные и не абстрактные. Это не формальная посдтилка под чейнить юникс вфс. Тут помню довольно давно обсуждали что толком положить на рфс4 пингвина невозможно ибо она слишком большая и нестандартная. RFS4 и XFS это сложные системы не подпадающие под типичные определение фс, соответсвено функционал у них соответствующий. У RFS4 - плагины, раскрытые внутренние интерфейсы, нерантайм элементы, полное слияние с ОС. А XFS это вообще целая ОС внутри ОС...

Другое дело ext2..4, rfs3, jfs, ntfs, ufs1 - вот они то и есть подстилки под вфс которым их надо тщятельно загримировывать, что и делается. Называть их уровень, уровнем студенческого поделия язык не поворачивается, но... и называть их кроме как формальной подстилкой непозволяет их банальность. То что от них требуют среднестатистические юниксоиды они исправно выполняют, этим для них все и заканчивается.

>кто нибудь ext4 пользуется ? насколько там устоялся формат, не будет ли менятся в будущем ? хочу винт файлопомойки на 750Г под ext4 отформатить интересует не придется ли в будущем переформатить...

Если добавят новый функционал, и захотите его использовать - придется переформатировать, а существующий меняться не будет (он вообще один и тот же со времен ext2 - обратная совместимость).

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

jfs это что, на джаве?!

Вполне, только один изменённый байт в файле может поменять весь его сжатый образ, и вам придётся сбрасывать на диск весь файл, вместо одного 1 байта в случае без сжатия.

Кроме того, сжатие увеличивает шанс потерять данные, если у вас происходит аппаратный сбой во время записи.

Вопрос не в затратах на сжатие (LZO алгоритм работает _очень_ быстро), а в возможных издержках.

Короче, компрессия не всегда нужна, что в Windows'e очень хорошо реализовано - вы выбираете какой файл сжимать, а какой нет. Правда некоторые грамотеи жмут свойства логического диска и применяют сжатие ко всему диску.

Кстати, вас никогда не смущало, что swap файл в Windows нельзя сжимать? Можете даже отключить своппирование, reboot, создать пустой сжатый файл, а потом включить обратно swap. Файл будет не сжат. ;-)