бенчмарк для тестирования производительности жестких дисков и ФС.

Команда: time /bin/cp -R /usr/share/ /mnt/temp/
Файлы: 614.4Мб, 3537 каталогов, 44494 файлов

ext2 @ defaults:
real	4m10.414s
ext2 @ noatime, nodiratime:
real	4m12.013s

reiserfs @ defaults:
real	2m52.809s
reiserfs @ noatime, nodiratime, notail:
real	2m44.510s

xfs @ defaults:
real	2m48.177s
xfs @ logbufs=8, logbsize=256k:
real	2m48.807s
xfs @ logbufs=8, logbsize=256k, noatime, nodiratime:
real	2m48.889s

ext3 @ defaults:
real	3m0.856s
ext3 @ noatime, nodiratime:
real	3m8.768s
ext3 @ noatime, nodiratime, data=journal:
real	3m1.502s

Обязательная погрешность — 5с, рекомендуемая — 10с. Вообще, для таких вещей есть пакеты вроде bonnie++, которые показывают, где именно ФС сливает.

> real 4m10.414s

ext2 @ noatime, nodiratime:

real 4m12.013s

сие очень странно. кстати, реквестирую еще и тест с ext4 data=writeback

ну как видишь - reiserfs рулит и у тебя - причём именно с notail(в том числе)
обязательная погрешность - ересь!
тем более если она стабильна
кстати - почему не вижу сбросов кэшей?
и что есть /mnt/temp/ ?

>сие очень странно.
++

>> сие очень странно.

Погрешность. Эти опции имеют некоторое влияние на скорость чтения, при записи менее актуальны. Я их учитывал для галочки.

реквестирую еще и тест с ext4 data=writeback

В 26-ом ведре только ex4dev, не думаю, что это имеет смысл.

no comments

Флэшка transcend

Использовался каталог
$ du -sh /usr/share/
1,3G   /usr/share/

Фс создавал так:
mkfs.ext2 -O ^filetype,^resize_inode,^ext_attr -m 0 -I 128 -v /dev/sdc
и
mkreiserfs /dev/sdc -f

Монтирвал так:
mount /dev/sdc /media/ -t ext2 -o noacl,nouser_xattr,noatime,nodiratime
и
mount /dev/sdc /media/ -t reiserfs -o noatime,nodiratime,noacl,nouser_xattr,notail

Тестил так:
sync; echo 3 >/proc/sys/vm/drop_caches
nice -20 tar c /media/ |pv >/dev/null

ТРИЖДЫ с каждой фс,

результаты:
ext2
1.12GB 0:01:36 [11.8MB/s] - все три раза ОДИНАКОВО.

reiserfs
1.12GB 0:01:46 [10.7MB/s] - аналогично три раза результаты сошлись.

Мне скринкаст записать, или в СПБ к тебе приехать?

На hdd разница была бы больше, как в той моей теме.

>> кстати - почему не вижу сбросов кэшей?

echo 3 > /proc/sys/vm/drop_caches и sync; sync; sync выполнялись после каждого монтирования и отмонтирования.

>> и что есть /mnt/temp/

Каталог, блин. Описание /usr/share я привёл.

>Реквестирую результаты прогона Bonnie++

Синтетические тесты не нужны!

Синтетические тесты не нужны!

4.2. Просто мне было жалко времени гонять Бонни++

>Каталог, блин.
т.е. ты писал на винт? о_О
почему не тмпфс?
не думал что затыки на стороне винта могут быть?

ну у меня флешка silicon_что-то там
ты серьёзно думаешь что я сам сгенерил выхлопы?

Да я уже хз..

не думал что затыки на стороне винта могут быть?

Вряд ли.

почему не тмпфс?

Как-то в голову не пришло. Возможно, потом повторю, но сейчас уже лень.

https://dl.dropbox.com/u/9454972/screen135.png
тоже думаешь рисовал в гимпе? :)

Пыщъ тебе, с ненастроенным dwm:
http://ompldr.org/vNXprbg
http://ompldr.org/vNXprcQ

>Синтетические тесты не нужны!

По скорости записи множества мелких файлов оценивать производительность фс как-то странно, не?

>По скорости записи множества мелких файлов

Где запись? ГДЕ? Перечитай тему ещё раз.

>>> почему не тмпфс?

Как-то в голову не пришло.

Работник фороникса детектед.

Без паники

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

>Где запись? ГДЕ? Перечитай тему ещё раз.

Признаю, был неправ. Но скорость чтения мелких файлов тоже еще не все :)

ошибаешься
что есть как не мелкие файлы /usr /etc /lib ?

а можно кодом и без лишнего мусора?
просто реально очень тяжко читать скрины

кстати - хз как на записи много_мелких_файлов, но на записи одного файла мелкими кусками (читай торренты) рейзерфс делает на раз экст2
это так - лирическое отступление

Это то же, что в посте выше ;)

А ext4 c barrier=0,data=writeback?

http://www.linux.org.ru/jump-message.jsp?msgid=5491264&cid=5502312
:)

>на записи одного файла мелкими кусками (читай торренты) рейзерфс делает на раз экст2
Это с O_DIRECT?
Или без пре-аллокации? Тогда можно поверить в то, что на reiserfs жутчайшая фрагментация чуть меньше страшна, чем на ext2.
Ну и на торрентах ext4 за счёт экстентов и умной аллокации рвёт reiserfs. Без вариантов.

какой нафиг директ?
какая пре-локация?
просто dd бла-бла-бла и всё
с экст4 не сравнивал - по-мне так сырая - ну её - не достойна она моей машинки!

>Спасибо, посмотрю. ПРо sync я тоже подумал, но ведь sync не должен вешать систему намертво?

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

Год сидел на reiser4+lzo, переехал на btrfs+gzip, стало намного лучше. Сохранность данных на ноуте меня не волнует, ибо бекапы.

вообще-то любой уважающий себя ноут умеет посылать сигнал «всем спать!» при заряде батареи в 1-2%%

>просто dd бла-бла-бла и всё
Вообще-то, торрент-клиенты «просто dd» не делают.

с экст4 не сравнивал - по-мне так сырая - ну её - не достойна она моей машинки!

Может, пора переходить с 2.6.18 на что-нибудь посвежее? В свежих ядрах, кстати, есть опция «использовать ext4 для ext2/3».