Фигасе xfs отжигает :D

С третьей попытки xfs отработала без ошибки - 63,0 сек. (Распаковка по-прежнему большая - 367,5сек.)

Бабе — цветы, детям — мороженое!

XFS -- isoшники хранить, фильмы, и музыку. А для всякого хлама,
который не жалко потерять (кеш squid'а, ccache, etc.) надо или
взять другую ФС (ext2 или reiserfs), или подкрутить опции mount
(-o logbufs=8) и mkfs.xfs (-l size=8192b).

> Закончился первый проход теста времени работы emerge при /usr/portage

А, гентушник! Вот почему важно, как быстро заливается файлО в /usr :)

> xfs - 499,9 (и в результате ошибка sqlite3-базы)

Мелкие файлы в xfs располагаются непосредственно в inode. Потому запись
таких файлов -- это операция с мета-данными. Потому ожидать большой
скорости от xfs в таком режиме -- по меньшей мере наивно.

> xfs показала чудовищное время распаковки архива с портежем (непрерывно
> горела лампочка HDD):

Ага, каждый мелкий файл -- транзакция (грубо говоря).

Что же касается ошибки, то это скорее всего глюк библиотеки и/или программы,
работающей с базой (начиная с того, что где-то забыли вставить fsync,
заканчивая тем, что gcc -O3 прикольнулся). Но вполне может быть и глюк XFS.

>XFS -- isoшники хранить, фильмы, и музыку.

Ну, это для неё и заявлялось. Просто у этой FS много сторонников, утверждающих, что она и с мелочью прекрасно работает. Поэтому тоже и тестировалась :)

...

Кстати, вариант с имитацией фрагментации - это вообще чума какая-то. ext2/ext3/ext4 выполняют копирование портежа из tmpfs с предварительным созданием половинного файла в те же 5 потоков за 27-28 минут. Только-только до jfs дело дошло :) При чём в случае ext2, похоже, какая-то ошибка на копировании возникла, потому что портеж при первом поиске начал делать Global Update. Так что emerge занял 11 минут против традиционных полутора минут... Тот ещё стресс-тест для ФС вышел :)

...

А по поводу XFS - думаю тут, не воткнуть ли второй винт, отрезав раздел гигов на 30 и пощупать имитацию торрент-раздачи. Только как - не придумал ещё. В голову приходит заполнить 1.4Гб РИПами, взять потоков 10 и дёргать случайные куски из случайных мест файлов. Насколько такой тест будет адекватным? Вопрос только - как средствами shell правильно обращаться в середину файла? tail/head, полагаю, это не то получится.

Прокол получился с имитацией фрагментированности при многопоточном копировании портежа. У ext2/3/4/jfs уровень фрагментации не превысил 2%. Сейчас reiser4 копируется.

Зато одно ещё интересное наблюдение. При копировании в 5 потоков с tmpfs на раздел ext2/3/4/jfs тормозили машину очень сильно, сёрфиться даже в Симанки - мучение. А вот reiser4 - тормозит тоже заметно, но уже на юзабельном уровне получается. Посмотрим, сколько времени копирование займёт.

...

Есть у кого-то мысли по имитации практических задач?

Многопоточное чтение *.so из /usr отработали. Работу с портежем ещё постараюсь помучить на тему высокой фрагментации (хотя она у меня самого в реальном разделе около 1.8%).

Работу с выборочным чтением из больших файлов - это на будущее, когда второй винт высвобожу на эксперименты...

Раньше сделаю тест копиляции, т.е. выбор ФС для /var/tmp/portage. Хотя, полагаю, что победителем тут окажется reiser4.

Какими тестами можно определить эффективность ФС под /home? Под /etc? Или под /etc - это то же самое случайное чтение мелочёвки, что и для /usr?

...

О! Можно будет поиграть с ФС под mysql-базы. Но это придётся плотно извращаться уже с многопоточными SQL-запросами :)

>А вот reiser4 - тормозит тоже заметно, но уже на юзабельном уровне

Поторопился радоваться. Тормозит совершенно также :)

> Вопрос только - как средствами shell правильно обращаться в середину
> файла? tail/head, полагаю, это не то получится.

dd if=big.file of=/dev/null bs=1M skip=${OFFSET_IN_MBs}

Ага, точно... Надеюсь, десяток таких параллельных процессов отразит примерно нагрузку торрент-раздач :)

> > XFS -- isoшники хранить, фильмы, и музыку.

> Ну, это для неё и заявлялось. Просто у этой FS много сторонников,
> утверждающих, что она и с мелочью прекрасно работает.

Во-первых, при _чтении_ мелких файлов она таки неплохо работает. Во-вторых,
можно подобрать параметры так, что и на запись/удаление будет сносно работать.
То есть, отставать от ext2 и reiserfs все равно будет, но не в 10 раз,
а в 1.5 -- 2. Инструкции можно найти, нпример, здесь:
http://everything2.com/node/1479435

В-третьих, XFS -- это (по моему опыту) единственная ФС, на которой
по-человечески (без deadlock'ов и oops'ов) работают квоты и ACLи (я понимаю,
что на /var/cache/squid или /usr/portage это все нафиг не надо, но не
хлебом единым...). Падение производительности (пусть даже и в 2 раза) все
же лучше, чем kernel panic пару раз в месяц.

> Какими тестами можно определить эффективность ФС под /home?

Боюсь, тест будет не особо осмысленный и только собьёт с толку не шибко
опытных людей. У /usr, /var/cache, и т.п. задача на всех машинах примерно
одна и та же. А /home -- его каждый по-своему использует.

>Во-первых, при _чтении_ мелких файлов она таки неплохо работает.

Тесты чтения *.so в /usr не показали её преимуществ перед ext2, jfs и reiserfs и показали заметное отставание от reiser4. Хотя xfs и обошла на этом тесте ext3 и ext4dev.

>Во-вторых, можно подобрать параметры так, что и на запись/удаление будет сносно работать.

Тут спорить не буду, монтировалось всё с настройками по умолчанию. Только тест портежа был с noatime.

>В-третьих, XFS -- это (по моему опыту) единственная ФС, на которой по-человечески (без deadlock'ов и oops'ов) работают квоты и ACLи

Тут ничего сказать не могу, не пользуюсь ими :) Но соглашусь, что где-то это важно. Лишь ещё раз повторю, что «общий глобальный тест» принципиально невозможен, и тестирование я провожу только под свои задачи :)

>А /home -- его каждый по-своему использует.

Думаю, что пока речь идёт о хранении документов разного формата в нём, то вопрос производительности не стоит.

А вот конфиго-помойка прикладного софта в /home/ - то, на что, опять же, думаю, нужно обратить внимание.

...

Пока в голову приходит такой тест. Корявый, но ничего лучше не могу придумать. Имитируем «типичный» /home/.../.* Из скрипта запускаем иксы с автовходом. В автостарт ставим запуск/убиение Firefox (как бы определить, когда он полностью загружен?), Оперу, Nautilus/Konqueror, терминалку... Потом грохаем сессию. Измеряем, за сколько времени всё это произошло.

...

Пока непонятно, как измерять, когда загрузится то или иное приложение? Попытаться отслеживать его дисковую активность?

>Поторопился радоваться. Тормозит совершенно также :)

Гы. Зато меньше других тормозит xfs :D И время заполнения у неё вышло почти такое же, как у остальных (29 минут против 27 у reiser4/ext4).

...

В общем, тут я сплоховал с имитацией фрагментированности. Нужно как-то иначе...

> Тут спорить не буду, монтировалось всё с настройками по умолчанию.

Чо, и reiser без notail? omg

Анахуа мне reiser с notail? :)

Дык эта, reiser3 без notail - что водка безалкогольная. Скорость не та. Ну и похерить данные вероятность выше.

Да, действительно, влияние notail на reiserfs не хотел бы протестировать? Вот лично у меня reiserfs с notail.

Не хочешь ли замерить время emerge на squashfs? Лично у меня /usr/portage на squashfs.

Ты спрашиваешь, какие ещё практические задачи можно погонять. Почему бы не засечь время распаковки сорцов ядра (из .tar) и время удаления каталога с сорцами ядра?

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

>Да, действительно, влияние notail на reiserfs не хотел бы протестировать?

Вчера тест подправил на эту тему, но ещё не прогонял. М.б. сегодня посмотрю.

>Не хочешь ли замерить время emerge на squashfs?

Подумаю ещё. Тут пока работы много накопилось :)

>Почему бы не засечь время распаковки сорцов ядра (из .tar) и время удаления каталога с сорцами ядра?

См. http://www.linux.org.ru/view-message.jsp?msgid=2827996

Там, как раз, была и распаковка (именно сорцов ядра из tmpfs), и удаление.

>Или наоборот - нашёл способ очистить все влияющие на ввод-вывод кэши?

Да, этот способ. В первом тесте кеш сбрасывал левым копированием 2Гб мелочёвки, а потом подсказали «sync && echo 3 > /proc/sys/vm/drop_caches»

замерь емердж со сжатым /usr/portage (опция mkfs.reiser4 -o create=ccreg40)?

Запускал тест у себя - результаты reiser4 впечатляют :)

ext3
>>>>>>> Заполнение файлами
real    0m47.888s
user    0m4.336s
sys     0m9.321s
>>>>>>> Свободное место
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda6              4925528    489048   4186272  11% /mnt/fs-test
>>>>>>> Случайное чтение всех файлов
real    0m21.725s
user    0m0.780s
sys     0m1.400s


reiser4 -o ccreg40,compress=gzip1
>>>>>>> Заполнение файлами
real    0m33.847s
user    0m4.420s
sys     0m9.069s
>>>>>>> Свободное место
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda6              4754932    152704   4602228   4% /mnt/fs-test
>>>>>>> Случайное чтение всех файлов
real    0m11.639s
user    0m0.820s
sys     0m6.656s

Скрипт считающий фрагментацию - попугаемерятель :) На reiser4 c компрессией он показывает больше 90% фрагментации
 при этом фс показывает самые лучшие результаты на чтении и записи.
После тестов перевел все разделы на reiser4 - / без компрессии, /home /usr /tmp /var с компрессией.
 Улучшения заметны даже визуально - особенно запуск firefox и OO. Пока заметил только одно неудобство
 - слишком долго монтируются разделы при загрузке - это только у меня или у всех ? 
Проходит до 10-15 сек пока лампа hdd перестает гореть (в это время все работает но тормозит). До этого была reiserfs.

reiserfs с notail монтировал? иначе "не совсем честно" получается:)

До тестов со сжатием (или notail для reiserfs) руки так и не дошли, но после перевода на reiser4 /usr и /var/tmp эффект ощутим:

qlop для некоторых пакетов, предпоследнее (reiserfs) и последнее (reiser4) время сборки:

mozilla-firefox-3.0_rc2: Fri Jun 6 09:32:36 2008: 6 minutes, 36 seconds
mozilla-firefox-3.0_rc3: Sat Jun 14 17:01:29 2008: 3 minutes, 27 seconds

xulrunner-1.8.1.14: Fri Jun 6 12:25:27 2008: 2 hours, 1 minute, 11 seconds
xulrunner-1.9_rc3: Sat Jun 14 16:01:35 2008: 59 minutes, 54 seconds

btrfs-progs-0.15-r2: Fri Jun 13 11:39:21 2008: 26 seconds
btrfs-progs-0.15-r2: Sun Jun 15 02:14:45 2008: 15 seconds

strigi-0.5.9: Fri May 16 13:14:23 2008: 11 minutes, 0 seconds
strigi-0.5.10: Sat Jun 14 17:52:14 2008: 7 minutes, 14 seconds

empathy-0.23.1: Tue May 6 13:19:57 2008: 7 minutes, 34 seconds
empathy-0.23.3: Sat Jun 14 17:04:56 2008: 5 minutes, 0 seconds

Пардон, зулраннер сравнил со версией другого слота. Вот так правильно:

xulrunner-1.9_rc2: Fri Jun 6 07:48:36 2008: 1 hour, 44 minutes, 0 seconds
xulrunner-1.9_rc3: Sat Jun 14 16:01:35 2008: 59 minutes, 54 seconds

Пока заметил только одно неудобство - слишком долго монтируются разделы при загрузке - это только у меня или у всех ? Проходит до 10-15 сек пока лампа hdd перестает гореть (в это время все работает но тормозит). До этого была reiserfs.

Попробуй dont_load_bitmap в опциях монтирования, а вообще почитай Documentation/filesystems/reiser4.txt (или можно читать прямо из патча)

>Пока заметил только одно неудобство - слишком долго монтируются разделы при загрузке - это только у меня или у всех ?

Если ты про reiser4, то у меня он монтируется мгновенно. И при загрузке, и при ручном монтировании.

>Если ты про reiser4, то у меня он монтируется мгновенно. И при загрузке, и при ручном монтировании.

Название опции dont_load_bitmap как бы говорит о том, что эти битмапы грузятся по умолчанию :) Другое дело, что у вас может раздел не такой большой (нужно считывать 4кб-блок через каждые 128Мб), или в патче к ядру это отключено, или вы просто этого не замечаете