Производительность файловых систем

>Автор, что Вы измеряли?

Ответ смотрите на http://balancer.ru/tech/forum/2008/06/t62136--Proizvoditel~nost~-fajlovykh-si...

>Также интересны многопоточные операции

В новом тесте, часть результатов из которого только что привёл, все операции выполнялись в 5 параллельных потоков.

>UFS, ZFS планируется?

Только то, что накладывается на gentoo-sources простым патчем. Пока это только reiser4. zfs есть через fuse, но, полагаю, это неинтересно :D

Второй тест готов: http://balancer.ru/2008/06/12/post-1562431.html

Если кто-то подскажет, как красиво изобразить графики с диапазонами - заранее спасибо.

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

>в реальности она образуется при других условиях.

На моей машине в /usr именно так. Обновляются пакеты - переписываются старые файлы.

Добавил на страницу архив со скриптами и логами и уточнил некоторые детали проведения.

> В общем, готовлю сейчас новую версию теста. Принимаются практические пожелания.

Первое и главное практическое пожелание - это определение значительности различий между системами. Т.е. имеет смысл найти отклонения для любого теста которое может быть достигнуто на одной файловой системе как путем изменения параметров этой системы так и проведение повторных тестов в разный момент времени. Для этого изучаются принципы DoE и статистики.

Без учёта данных факторов любой тест теряет свой смысл напрочь.

Ну естественно по мимо этого очень неплохо понимать что именно измеряется. Без понимания этого лучше лежать на диване.

Сильные различия между системами обязаны объясняться доступной информацией о них.

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

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

P.S. Я еще совершенно не затронул паралелльный доступ к данным, который имеет место быть в реальной жизни. Это тоже обстоятельство которое должно приниматься во внимание применительно к реальной жизни.

Успехов.

Закинул тест как отдельную новость. В т.ч. с краткими выводами по чтению. http://www.linux.org.ru/view-message.jsp?msgid=2830545

>Без учёта данных факторов любой тест теряет свой смысл напрочь.

У этого теста есть суровый и самый глубокий смысл. Он прямо ответил, какая ФС с дефолтовыми настройками будет лучшей для меня. С остальными просто поделился - может, кому-то будет полезно. Цель сделать всеобъемлющее многомерное тестирование не ставилась. Так как эта задача не имеет решения.

> Он прямо ответил, какая ФС с дефолтовыми настройками будет лучшей для меня.

Это говорит лишь о том, что Вы либо получаете информацию через космос, либо совершенно не понимаете что сами делаете.

В первом я не уверен. По этому такое признание в своей квалификации настораживает. В таком случае могу поделится сразу правильным ответом. Это 9.

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

Имхо - тесты очень интересные и безусловно заслуживают внимания, от себя лично огромное спасибо.

> На моей машине в /usr именно так. Обновляются пакеты - переписываются старые файлы.

Там, выше, я привел алгоритм организации жёсткой такой фрагментации.

>> Смонтированная с параметром ro

> Не факт. Дело в том, что журналируемые ФС делают journal replay, несмотря на ro.

Нет в жизни счастья...

:(

http://linuxgazette.net/122/TWDT.html#piszcz

>http://linuxgazette.net/122/TWDT.html#piszcz

hujeta

> Второй тест готов

хотелось бы и btrfs сравнить - оно собирается простым модулем к ядру. домашняя страница - http://btrfs.wiki.kernel.org/

БТРфс о_0

не вытерпел дочитать коменты, очень хотелось свой написать...

афтар протести еще vfat и ntfs-3g

а также можно и в винде потестить fat32, ntfs и ext2, ext3 с драйвером ext2fsd.

я на работе както форматнул ntfs в ext3 и проверил на чтение, ext3 оказался быстрее чем ntfs на 1 мб/с (точные цыфры не помню, или 45 и 44, или 55 и 54 мб/с)

и насчет reiserfs, на компе разделы /, /home, /tmp, /var, /usr и все reiserfs, примерно 20-30 раз вырубалось питание компа, и еще проблем с фс и данными не было. На компе крутятся apache, vsftpd, samba, mysql, zabbix.

Извеняюсь за нетерпение, посмотрев 4ю страницу коментов, уведел в тестах vfat и ntfs-3g

Оказывается ext3 делает ntfs-3g и vfat. Ну с линуксами понятно, мня продолжает интересовать вопрос, в винде ext3 тоже делает ntfs?

В понедельник попробую потестить, и если ext3 порвет ntfs, тогда получится что МС не могут для мвоей ОС сделать нормальную ФС! :)

> http://linuxgazette.net/122/TWDT.html#piszcz

+1

JFS рулит, на всех серваках работает.

>хотелось бы и btrfs сравнить

Если я правильно понял, оно ориентировано на мультидевайсы? Рейды всякие и т.п...

> Если я правильно понял, оно ориентировано на мультидевайсы? Рейды всякие и т.п..

ну она планируется как конкурент ZFS по фичам (снапшоты, subvolumes), это может не только на мультидевайсах пригодиться...

а так же является базовой ФС для CRFS - будущего конкурента NFS от оракла..

>в iozone, postmark, dbench, maildir и file creation benchmarks на 4-головом Xeon с 4гб памяти и 10k scsi seagate диском 300гб на Adaptec AIC7902 Ultra320

не серьезно совершенно, как и тест топикстартера. если тестировать производительность FS при работе с файлами a la maildir, то нужно по-честному взять imap сервер (вроде курьер не кеширует ничего, хотя не факт) и натравить на него пару тысяч клиентов и так со всеми тестами: вот так вот ведет себя ФС при использовании на файлсервере, HTTP-сервере, сервере БД и т.п. А сколько у меня ядро распаковывается мне совершенно плевать, я его раз в три года компилирую.

Balancer> Раздел не размониторвался, кеш сбрасывался копированием 2Гб мелкого мусора в других разделах.

man sync

" SYNC(1) User Commands SYNC(1)

NAME sync - flush file system buffers

SYNOPSIS sync [OPTION]

DESCRIPTION Force changed blocks to disk, update the super block.

--help display this help and exit

--version output version information and exit

AUTHOR Written by Jim Meyering. "

> Btrfs is under heavy development, and is not suitable for any uses other than benchmarking and review

Видно, что Крису не приходилось разрабатывать серьезные системы "от начала и до конца": полностью избежать компромиссов с изначальной производительностью редко когда удается. Реализуй всю функциональность - тогда и будем смотреть на бенчмарки :)

Гляжу, высказывания о Reiserfs только положительные. А у меня однажды после нажимания на reset в процессе загрузки компа эта ФС померла: предложила перестройку дерева, после которой почти все данные испарились. С ext3 такого не было. С тех пор и не использую reiser.

>Удаление файла на 30 гигов.
>haywire (*) (12.06.2008 1:05:52)
рип фильма? гнусный перат-копераст

>> Дичайшая фрагментация всех без исключения линуксовых файловых систем — до UFS2 ещё не доросли.

>Рекомендуете??

не нужно слушать этого красноглазого фанатика-линуксоненавистника. я фряху уже почти 6 лет использую и могу сказать что все не так радужно как в его постах. он явно носит огроменные розовые очочки

> Balancer> Раздел не размониторвался, кеш сбрасывался копированием 2Гб мелкого мусора в других разделах.

> man sync

Кеш и буфер - две большие разницы.

Кеш можно быстро сбросить так: sysctl -w vm.drop_caches=3. 3 сбрасывает все кеши в ядре, какие вообще можно сбросить. Возможно, достаточно 1 или 2, надо думать над этим.

>хотелось бы и btrfs сравнить

Собрал. Но по второму тесту не знаю, когда её прогоню, а по первому уже не буду из-за его малой выразительности :)

Сейчас делаю третий тест, с какой FS быстрее всего будет работать Gentoo-portage. Включу туда и btrfs, и вариации с разными опциями монтирования. Правда, гонять буду уже не в чистом виде, а под иксами. Но по-прежнему с высоким приоритетом :)

>> man sync

> Кеш и буфер - две большие разницы.

sync я ещё в первом тесте в первую очередь пробовал - пофиг, результат оказывается всё равно сильно кешированным. Про echo 3 > /proc/sys/vm/drop_caches не знал, так что и "сбрасывал" кеш большим копированием. Реально помогало :) Но сейчас, конечно, через drop_caches сбрасываю

Третий тест уже в новости флеймить не буду, в talks'ы закину ;)

Ещё будет четвёртый - использование в /var/tmp/portage для сборки. Но тут, есть подозрение, будет почти пофиг, ибо кеш сказываться будет сильно. Но всё равно проверю. Вдруг какая-то ФС будет эффективнее ;)

btrfs не создаётся:

mkfs.btrfs /dev/sda6

failed to zero device end -5

...

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

>нужно по-честному взять imap сервер (вроде курьер не кеширует ничего, хотя не факт) и натравить на него пару тысяч клиентов

По сцылке не ходим? Почитайте на досуге, как проводилось тестирование, а потом высказывайте мнение.

Первоначальный автор провел тестирование для себя и показал результаты. Данные для своей задачи он нашел и сделал выводы.