Тестирование ФС (reiserfs v4 в сравнении.)

[Angel_13th]

Вот тут http://linuxgazette.net/122/piszcz.html, было проведено тестирование reiserfs v4, reiserfs v3, ext2, ext3, XFS, jfs. О результатах узнаете сами.

[t.t]

Интересное тестирование. Столько слышал о производительности рейзера, что всё хотелось попробовать, теперь решил на обозримое будущее: остаюсь на ext3. Единственные две задачи из протестированных, где она безнадёжно отстаёт -- создание фс и резка 10М-файла на 1000-байтные кусочки -- мне ещё ни разу (ну, кроме создания фс при установке года два назад, конечно) не понадобились, и не факт что вообще когда-то понадобятся.

[Angel_13th]

Народ на opennet по большей части не доволен данным тестированием, и я с ними согласен. Много нестыковок.

[t.t]

Народ на opennet по большей части не доволен данным тестированием, и я с ними согласен. Много нестыковок.

↑

Нестыковок с чем? Я не "ради поспорить", мне действительно интересно. Просто чем эти результаты привлекли моё внимание -- они не однобокие, в отличие от почти всех других, которые я до сих пор видел. Когда по каким-то тестам получается, что "рейзер рвёт всех" по всем параметрам -- я в это не очень-то верю.

[KiWi]

reiser4 -- похоже, действительно тормозной(при своём "тестировании" списал всё на нестабильность ФС(ну не дело это, когда после каждого ребута(reset) что-нибудь да портится...))...
а так -- ext3 и reiserfs -- где-то ext3, где reiserfs лучше...

[Angel_13th]

Чем вызвана такая нагрузка на процессор во время копирования, там же не 166?

[t.t]

а так -- ext3 и reiserfs -- где-то ext3, где reiserfs лучше...

↑

Так и я о том.

[chitatel]

Угум-с... Несколько дней назад обнаружил ссылку на LOR'e и уже тогда там был огроменный флудообмен .
В ФС не спец, но впечатления субъективные - насчет ext2/3 и reiser, - именно такие, как в тесте. В конце ЛЮБОГО теста надо всегда писать - "Все тесты синтетические". Фраза не вполне понятная, но суть передает правильно - тест тестом, а лес - лесом.
Опыт у меня с reiser3 был плачевный, поэтому ext3 - выбор нашего чОловика:"тёсево, тёсево" и сердито.

[Angel_13th]

chitatel Я могу сказать с точностью, до наоборот. Имею плачевный опыт работы с ext3. Всегда один единственный резет, приводил систему в траур, с рейзером такого не замечал.

[t.t]

chitatel Я могу сказать с точностью, до наоборот. Имею плачевный опыт работы с ext3. Всегда один единственный резет, приводил систему в траур, с рейзером такого не замечал.

↑

Может, с ext2 ? У меня ext3 уже третий год минимум, свет вырубался за это время не один десяток раз -- и ни единой проблемы не было, всё с журнала восстанавливалось.

[Angel_13th]

t.t Было это давно, при установке Mandrake Linux 9.2, всегда выбирал ext3. После внезапной перезагрузки вылезала надпись что то там про Ctrl+D, и все.

[chitatel]

chitatel Я могу сказать с точностью, до наоборот. Имею плачевный опыт работы с ext3. Всегда один единственный резет, приводил систему в траур, с рейзером такого не замечал.

Охотно верю. Но у меня за все время использования Linux'a (года 4 попеременно Lin-Win, весь прошлый год - только Linux) ext3 умер, может, раза 2-3. А скорее это я её убивал. С ext2 было похуже. Reiser3 умирал обязательно и восторженно, когда пытался его использовать. Mdk10.1 не захотел на него вставать ("не встало у него..." на reiser совсем, хотя, возможно, дело и не в этом.
Ну, это, собственно, флудерастничание типа LOR'овского Еще раз повторю - верю и "все тесты - синтетические"

А вот может правы те, кто обратил внимание на процессор - 500Mhz всего у тестера было-то? А не тут ли собака зарыта?

[t.t]

t.t Было это давно, при установке Mandrake Linux 9.2, всегда выбирал ext3. После внезапной перезагрузки вылезала надпись что то там про Ctrl+D, и все.

↑

Я ещё вот о чём не подумал: это ведь зависит и от включённых опций журналирования. Видимо, в мандрейке несколько другие умолчания, чем в дебиане.

[Angel_13th]

Могу сам провести тестирование, при наличии готовых скриптов. Или предлагаю создать в проектах нашего форума отдельную тему о написании скриптов для тестирования, ибо сам я в этом как конь по телефону.

[KiWi]

Angel создавай, посмотрим

[alastor]

Да они б еще на 386-м потестировали, глядишь что-нить древнее б да выиграло Ясен перец (ну на всякий случай ИМХО ) что для современных фс нужны современные машины. Интересно было б посмотреть на результаты этих тестов, скажем на P4-2ГГц или еще лучше на Athlon64.

[Sparky]

Тесты похожи на правдоподобные B)
Сам использую ext3 для /boot раздела а для остального reiser v3.

А вот может правы те, кто обратил внимание на процессор - 500Mhz всего у тестера было-то? А не тут ли собака зарыта?

ИМХО, это не должно влиять, так как все файловые системы из теста кроме reiser v4 появились задолго до того, как PIII-500 стал считаться слабой машиной. Опять же для работы с ФС не должна мощность процессора быть столь критичной. Это же не рендеринг в самом деле B) С ФС всем нужно работать и на слабых машинах и на мощных.

Да они б еще на 386-м потестировали, глядишь что-нить древнее б да выиграло Ясен перец (ну на всякий случай ИМХО ) что для современных фс нужны современные машины. Интересно было б посмотреть на результаты этих тестов, скажем на P4-2ГГц или еще лучше на Athlon64.

Да кто тебе сказал то чушь такую? Не охота флеймить, но ext2 уж никак современной ФС не назовешь ( по крайней мере по ее возрасту. ) И опять же, повторюсь... Работа с ФС это не работа с трхмерной графикой, а вполне обыкновенне операции, которые должны осуществляться достаточно быстро на любом относительно старом железе!

Что за гигантомания такая? Давайте тогда сразу на Крее тестировать ^_^

[Angel_13th]

Sparky Там в тестировании была и загрузка процессора, и почти везде она была порядка 80-99%. B)

[Sparky]

Sparky Там в тестировании была и загрузка процессора, и почти везде она была порядка 80-99%. B)

Так я про это и говорю. Не должно такого быть, думаю, что проблемма не в мощности процессора. B)

[t.t]

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

И насчёт загрузки проца. У меня пень4-2.8. Только что в порядке эксперимента провёл два из приведенных тестов:

Код: Выделить всё

t:~/123$ for i in `seq 10000`; do touch $i; done
t:~/123$ for i in `seq 10000`; do rm -f $i; done

Действительно в процессе них процессор был загружен почти на 100%.

[elide]

честно скажу - статью не читал (:
но судя по тесту, который привел t.t, это совершенно неправильная статья, которая к производительности ФС никакого отношения 6не имеет (:
задумайтесь вот над такими результатами....

Код: Выделить всё

elide@rebirth| ~ >> mkdc 123
elide@rebirth| ~/123 >> time for i in `seq 10000`; do touch $i; done
real    1m10.954s
user    0m49.686s
sys     0m14.137s
elide@rebirth| ~/123 >> time for i in `seq 10000`; do rm -f $i; done
real    1m16.209s
user    0m50.134s
sys     0m15.494s
elide@rebirth| ~/123 >> time for i in `seq 1000`; do touch 1$i 2$i 3$i 4$i 5$i 6$i 7$i 8$i 9$i 0$i; done
real    0m7.440s
user    0m4.994s
sys     0m1.800s
elide@rebirth| ~/123 >> time rm -f *
real    0m0.559s
user    0m0.034s
sys     0m0.522s
elide@rebirth| ~/123 >>

разница в скорости удаления более чем в 130 раз - это вам не просто так...
сокращение числа вызовов touch при создании файлов в 10 раз приводит к росту скорости в 9.5 раз. можно сделать вывод, что затраты на собственно создание файла несравнимо меньше, чем затраты на запуск и остановку самого процесса touch. и уж чего тогда удивляться загрузке процессора? процессор здесь занимается не работой с ФС, а запуском и остановкой процессов. это, надо сказать, достаточно ресурсоемкая операция....

[Dark_Savant]

хм.. ну не знаю, что нужно делать с ext3, чтоб ее убить. у меня ни разу не было каких либо проблем. при некоректном отключении все превосходно востанвливалось. смонтированы обычно в ordered mode

[Sparky]

честно скажу - статью не читал (:
но судя по тесту, который привел t.t, это совершенно неправильная статья, которая к производительности ФС никакого отношения 6не имеет (:

Вот мои результаты:

time for i in `seq 10000`; do touch $i; done

real 0m13.740s
user 0m4.056s
sys 0m9.321s


time for i in `seq 10000`; do > $i; done

real 0m2.644s
user 0m1.116s
sys 0m1.436s


time for i in `seq 10000`; do rm -f $i; done

real 0m13.588s
user 0m4.132s
sys 0m8.469s


time for i in `seq 1000`; do touch $i; done

real 0m2.592s
user 0m0.660s
sys 0m1.820s


time for i in `seq 1000`; do > $i; done

real 0m0.212s
user 0m0.052s
sys 0m0.120s


time for i in `seq 1000`; do rm -f $i; done

real 0m2.493s
user 0m0.692s
sys 0m1.728s

Загрузка ЦП в районе 30%.
Платформа:
AMD Turion 64 ML-34/512MB RAM/
Система:
Fedora Core4 x86_64 - 2.6.14-1.1656_FC4


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

Так что прежде чем критиковать, полезно все же читать

[t.t]

но судя по тесту, который привел t.t, это совершенно неправильная статья, которая к производительности ФС никакого отношения 6не имеет (:

↑

Ну, тут два момента. Во-первых, то, что уже сказал Спарки: накладные расходы -- ФС-независимы. А во-вторых, с "тестами" это я вчера протупил -- сонный уже был. А понял, что протупил, уже когда комп вырубил. Не факт, что автор тестов протупил так же, как и я

Код: Выделить всё

t:~/123$ time touch `seq 10000`

real    0m3.072s
user    0m0.040s
sys     0m2.816s
t:~/123$ time rmf *

real    0m0.156s
user    0m0.041s
sys     0m0.107s
t:~/123$ time for i in `seq 10000`; do touch $i; done

real    0m19.111s
user    0m5.067s
sys     0m12.798s
t:~/123$ time for i in `seq 10000`; do rm -f $i; done

real    0m16.535s
user    0m5.274s
sys     0m10.162s

Отсюда очевидно, что примерно 16 секунд занимает цикл, т.е. те самые накладные расходы...

Насчёт теста мне теперь кажется, что для создания файлов и каталогов действительно использовался цикл, а удаление проводилось просто по rm -rf *. Во-первых, посмотрите на временнУю шкалу: для touch и mkdir все цифры зашкаливают за 30 секунд, тогда как для rm они в случае с ext2/3 меньше чем полсекунды для файлов и не больше нескольких секунд для каталогов. А во-вторых я посмотрел на загруженность процессора: с циклами она действительно доходила до 100%, тогда как без них такое наблюдалось только для создания каталогов, а для создания файлов максимальное замеченное мной число было около 46%.

[v04bvs]

Надо тестировать скорость простой программой на C а не шелл-скриптами, имхо. Тогда всё будет гораздо чище.

[t.t]

Надо тестировать скорость простой программой на C а не шелл-скриптами, имхо. Тогда всё будет гораздо чище.

↑

Извините, а rm и touch -- это не простые программы на си?

[Sparky]

Надо тестировать скорость простой программой на C а не шелл-скриптами, имхо. Тогда всё будет гораздо чище.

↑

Извините, а rm и touch -- это не простые программы на си?

Я так понимаю v04bvs имел ввиду работу с ФС на уровне системных вызовов

[Bloody]

p4-2.4@800 1024 sata80-reiser4
cpu - 15-30 % load

Код: Выделить всё

bloody test # time for i in `seq 10000`; do touch $i; done

real    0m26.101s
user    0m7.922s
sys     0m17.602s
bloody test # time for i in `seq 10000`; do rm -f $i; done

real    0m27.115s
user    0m8.126s
sys     0m18.444s
bloody test # time for i in `seq 1000`; do touch 1$i 2$i 3$i 4$i 5$i 6$i 7$i 8$i 9$i 0$i; done

real    0m3.350s
user    0m0.832s
sys     0m2.502s
bloody test # time rm -f *

real    0m1.102s
user    0m0.097s
sys     0m1.004s
bloody test #

[t.t]

Надо тестировать скорость простой программой на C а не шелл-скриптами, имхо. Тогда всё будет гораздо чище.

↑

Извините, а rm и touch -- это не простые программы на си?

Я так понимаю v04bvs имел ввиду работу с ФС на уровне системных вызовов

Да всё равно накладные расходы на любой фс будут одинаковы -- ты сам об этом говорил.

[Sparky]

Надо тестировать скорость простой программой на C а не шелл-скриптами, имхо. Тогда всё будет гораздо чище.

↑

Извините, а rm и touch -- это не простые программы на си?

Я так понимаю v04bvs имел ввиду работу с ФС на уровне системных вызовов

Да всё равно накладные расходы на любой фс будут одинаковы -- ты сам об этом говорил.

А я и не спорю. Просто расшифровал, что человек хотел сказать