LINUX.ORG.RU

Тестирование производительности файловых систем, на этот раз с reiser4 и конкретной задачей

 ,


0

1

Продолжение и развитие темы http://www.linux.org.ru/view-message....

  • Были добавлены reiser4 и, для оценки, vfat с ntfs-3g.
  • Поставлена конкретная задача - изучение параллельного случайного чтения *.so из /usr/lib/
  • Был задействован механизм имитации роста фрагментации при обновлениях системных библиотек
  • Была произведена серия из трёх опытов, дабы уменьшить влияние разбросов.
Результаты и подробности - по ссылке.
    Вывод для тех, кто не любит ходит по ссылкам, места на случайном многопоточном чтении файлов распределились так:
  • Первое место взял однозначно reiser4 c результатом 55 сек.
  • Второе место поделили ext2, jfs, reiserfs (т.е. 3-й) и xfs с результатами 62-76сек.
  • Третье место - ext3, ext4dev и vfat с 86..106 сек.
  • Аутсайдером оказалась, что не удивительно, ntfs-3g (125 сек.).

>>> Подробности

★★★★★

Проверено: UVV ()
Последнее исправление: cetjs2 (всего исправлений: 1)

Неужели нет заинтересованных компаний, которые смогли бы подхватить reiser4?

anonymous
()

Выигрыш reiser4 на случайном доступе по сравнению с reiserfs и jfs объясняется скорее всего именно логической структурой FS (Dancing Trees vs. B+-Trees), что никого удивлять не должно :)

frame ★★★
()

>Первое место взял однозначно reiser4 c результатом 55 сек.

Если есть возможность, монтируй с noatime - получше работает...

anonymous
()

Наверно теперь Рейзер4 никогда не будет включена в стабильное ядро. А жаль.

hibou ★★★★★
()
Ответ на: комментарий от frd

>может написать петицию чтобы Ганса в клетке заставили писать райзерфс ;-)

и скастить срок, если хорошо кодить и вести себя будет.

anonymous
()
Ответ на: комментарий от fyrer

Дык, когда в тюрьму сажают, то не спрашивают, нужна ли заключённому та или иная работа :)

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от anonymous

> Интересно сравнить reiserfs с ZFS...

Кстати да.

s0n1k ★★
()

То, что ext3 - самая тормозная при параллельных запросах - это было и так известно :(

Led ★★★☆☆
()
Ответ на: комментарий от frame

dancing trees не имеет никакого отношения к структуре FS, это техника флаша грязных нодов дерева при кототрой новые ноды дерева не алоцируют номера нодов на диске а имею фейковые номера во время балансировки с тем чтобы алоцировать их потом, на флаше и таким образом разместить ноды дерева в порядке нужном FS: минимум фрагментации всех типов, возможно союлюдая проавила фибров и все такое. А старые грязные ноды как я помню на флаше могут переалоцироваться с тем чтобы получить более "поавильные" номера нодов.

Banshee
()

Хотелось бы увидеть сравнения производительности линукс fs с виндовыми на винде и возможно с тем что работает на солярисе (zfs?). Думаю данные сравнения будут более информативны.

Fredy
()
Ответ на: комментарий от Banshee

Класс, нашелся хоть один понимающий человек :) Действительно, dancing trees - лишь некий слой абстракции, препятствующий фрагментации и избавляющий от ненужных балансировок

http://jack.kiev.ua/linuxjournal/LJ/0109/6569.html :

>Reiser4 reduces the number of internal nodes, nodes containing pointers, from the number required for ReiserFS v3. The number of internal nodes required for ReiserFS v3 to store the 188MB Linux kernel 2.4.1 source code tree is 1,629. Reiser4 requires only 164. As a result, the amount of RAM required to store pointers to nodes is reduced dramatically in Reiser4.

вот поэтому Reiser4 и быстрее, т.к. ему приходится обрабатывать меньше метаданных

frame ★★★
()

Тесты - фигня, не приведена загрузка процессора и пожираемое время.

Ибо древняя мудрость гласит: как бы быстро не читались данные, но если проц на 100% занят оным чтением - то софту ничего не останется и быстрее софт не запустится.

Gharik
()
Ответ на: комментарий от Banshee

> dancing trees не имеет никакого отношения к структуре FS, это техника флаша грязных нодов дерева при кототрой новые ноды дерева не алоцируют номера нодов на диске

Сдается. что ты путаешь dancing trees с delayed allocation...

anonymous
()
Ответ на: комментарий от frame

> вот поэтому Reiser4 и быстрее, т.к. ему приходится обрабатывать меньше метаданных

Ну да, если б все так просто было, все жили бы в Сочи :)

anonymous
()
Ответ на: комментарий от Gharik

>Ибо древняя мудрость гласит: как бы быстро не читались данные, но если проц на 100% занят оным чтением - то софту ничего не останется и быстрее софт не запустится.

Ибо мудрость kernel developer'а гласит: не снимать блокировки с процесса до завершения его IO-запроса. Так что иди в жопу, профан красноглазый.

anonymous
()
Ответ на: комментарий от koTuk

Еще, если бы не разосрался со всеми, вообще было бы хорошо..

anonymous
()

> Первое место взял однозначно reiser4 c результатом 55 сек.

Ну надо же... Оказывается это был тест гонщиков...

Значит выходит, что лучшая машина для передвижения по городу это Феррари...

Мда... Что еще сказать об уровне автора...

Я бы на вскидку дал бы лет 17 - не больше.

Вот оно проявление плачевной ситуации с российским образованием...

С сайта: "В общем, по результатам этого теста, я теперь в раздумьях по поводу переползания на reiser4"

- Ежики плакали и кололись, но упрямо лезли на кактус...

lefsha
()
Ответ на: комментарий от Gharik

>Тесты - фигня, не приведена загрузка процессора и пожираемое время.

Вот тут согласен. Неплохо бы отметить нагрузку на процессор относительно данных тестов. Это таки важный для многих момент.

eduard_pustobaev ★★
()
Ответ на: комментарий от lefsha

>> Первое место взял однозначно reiser4 c результатом 55 сек.

>Ну надо же... Оказывается это был тест гонщиков...

>Значит выходит, что лучшая машина для передвижения по городу это Феррари...

Тут речь идет о linux и скорости фс - при чем тут вообще машины для передвижения по городу ? Это не сайт таксистов.

koTuk
()
Ответ на: комментарий от Banshee

Вы ж вроде участвовали в разработке reiser4, если мне не изменяет память. Интересно ваше мнение по поводу перспектив развития этой файловой системы, да и про текущее её состояние(баги, недоработки и всё такое). Если не лень, отпишитесь.

P.S. Юзаю reiserfs и вцелом не имею никаких проблем.

eduard_pustobaev ★★
()

Результаты любопытные, но если серьезно то какова была загрузка процессора и памяти? Для некоторых задач именно эти параметры крайне важны. Если автор возьмет на себя труд и включит эти характеристики в последующие тесты файловых систем думаю результаты получатся еще более интересными.

anonymous
()

Забавные данные. Если интересно могу послать скрипт для UDAV и картинку (PNG) с диапазонами ошибки. Пишите на mathgl.abalakin(at)gmail.com.

abalakin ★★
()
Ответ на: комментарий от anonymous

>Результаты любопытные, но если серьезно то какова была загрузка процессора и памяти?

Их измерить достаточно трудно в комплексе. Особенно - затраты памяти. Это ж в ядре, не прикладной задаче. Если смотреть загрузку CPU на отдельных тестах - можно обратить внимание на sys в отчёте time. В логах они есть.

А так - я теперь в новых тестах стараюсь ставить конкретные задачи, где загрузка CPU уже будет автоматически включаться в тест. Скажем, то же время отработки emerge.

KRoN73 ★★★★★
() автор топика
Ответ на: комментарий от abalakin

Странно. Почтовик почту принимает, тот же спам прямо сейчас понемногу сыплется...

KRoN73 ★★★★★
() автор топика

Да, reiser4 рулит по всем параметрам. Юзал бы её, если бы не одна ошибка. Может мне что-то дельное подскажет всемогущий All.

Проблема заключается в том, что когда на диске нет места, и какой-то процес пытается записать данные, то процес зависает, файл записывается битым куском, и при этом возникают тормоза, и в dmesg сыпятся ошибки. При этом бывает что бьются системные либы. После этого перезапускаюсь в init=/bin/bash, чекаю FS, и вижу валом ошибок. Впоследний раз юзал на 2.6.23. Не знаю, может с того времени что-то изменилось. Кроме этого, некогда не было проблем с этой FS.

iron ★★★★★
()
Ответ на: комментарий от iron

> Кроме этого, некогда не было проблем с этой FS.

Неработоспособность - это и есть единственная проблема, всё остальное - мелкие недостатки.

mv ★★★★★
()
Ответ на: комментарий от iron

> Проблема заключается в том, что когда на диске нет места, и какой-то процес пытается записать данные, то процес зависает, файл записывается битым куском, и при этом возникают тормоза, и в dmesg сыпятся ошибки. При этом бывает что бьются системные либы. После этого перезапускаюсь в init=/bin/bash, чекаю FS, и вижу валом ошибок. Впоследний раз юзал на 2.6.23. Не знаю, может с того времени что-то изменилось. Кроме этого, некогда не было проблем с этой FS.

Недавно поправили вот этими патчами: http://marc.info/?l=reiserfs-devel&m=120914767218495&w=2 http://marc.info/?l=reiserfs-devel&m=120914767118492&w=2

anonymous
()
Ответ на: комментарий от anonymous

> Недавно поправили вот этими патчами

Хмм... А тонны assert'ов - это для улучшения стабильности работы?

mv ★★★★★
()
Ответ на: комментарий от mv

> Хмм... А тонны assert'ов - это для улучшения стабильности работы?

Ну не знаю, про ассерты эти, вроде, немало уже клав избито было..

anonymous
()
Ответ на: комментарий от anonymous

Это значит, что Reiser4 online! И это хорошо :)

anonymous
()
Ответ на: комментарий от anonymous

>Недавно поправили вот этими патчами:

Ой пасибо!

iron ★★★★★
()
Ответ на: комментарий от koTuk

> Ганс - волшебник :) Его reser4 лучшая - ФС в мире.

Все инкарнации reiserfs НЕстабильны, под нагрузкой падают не реже раза в неделю, проверенно многими и многократно. Кроме того, при серьезной работе с данными (если не два гига брать, а хотя бы 200) начинают жутко тормозить на параллельном чтении и записи на страйпнутые рейды.

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

Die-Hard ★★★★★
()
Ответ на: комментарий от Die-Hard

>Все инкарнации reiserfs НЕстабильны, под нагрузкой падают не реже раза в неделю

Почему у меня ни одного падения не было за 4 года работы на трёх HDD на сервере, выполняющим в пике более 1000 SQL-запросов в секунду из которых процентов 20 - update и отдающий юзерам около миллиона хитов в сутки? :) - http://admin.airbase.ru/globalstat/

А вот ext3 до этого пару раз на заметно меньшей нагрузке на той же машине ломался...

Другие FS под высокими нагрузками, правда, не испытывал. Но, вот, обычное многопоточное копирование портежа только что на домашней машине показало, что ext2, xfs и vfat на нём ломаются через раз :)

KRoN73 ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.