тест проведён на старом 2.5" ide жестком диске

root@asus:~# hdparm -I /dev/sda

/dev/sda:

ATA device, with non-removable media
        Model Number:       FUJITSU MHV2040AH                       
        Serial Number:      NT30T632F337
        Firmware Revision:  00830096

root@asus:~# fdisk -l

Disk /dev/sda: 40.0 GB, 40007761920 bytes
255 heads, 63 sectors/track, 4864 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000a8984

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1          24      192748+  83  Linux
/dev/sda2              25         997     7815622+  83  Linux
/dev/sda3             998        4681    29591730   83  Linux
/dev/sda4            4682        4864     1469947+  82  Linux swap / Solaris
root@asus:~#


для загрузки с btrfs было пересобрано ядро.

и так:
/usr/src - btrfs
/mnt - ext4

root@asus:/usr/src# time tar xvf linux-source-2.6.32.tar.bz2
[............]
real    2m4.749s
user    0m42.080s
sys     0m8.721s


root@asus:/mnt# time tar xvf linux-source-2.6.32.tar.bz2
[............]
real    1m56.302s
user    0m41.650s
sys     0m4.934s

root@asus:/usr/src# dd if=/dev/zero of=FILE bs=1024 count=100000
100000+0 записей считано
100000+0 записей написано
скопировано 102400000 байт (102 MB), 3,46792 c, 29,5 MB/c

повторив 10 раз я получил среднюю цифру 27.05


root@asus:/mnt# dd if=/dev/zero of=FILE bs=1024 count=100000
100000+0 записей считано
100000+0 записей написано
скопировано 102400000 байт (102 MB), 2,6686 c, 38,4 MB/c

повторив 10 раз я получил среднюю цифру 37.24


я не хочу рисовать графики как всеми любимый Alve, который заявил ещё чёрт знает когда что БТР рвёт всех, я просто желаю всем тестерам производительности для linux систем делать тесты, с расчётам что их кто-то повторит.

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

2

ext4 много чего держит в кэше, а сбрасывает по мере возможности. Попробуйте смонтировать разделы с опцией sync.
У btrfs много интересных плюшечек заявлено. Возможно по мере их реализации скорость работы потихоньку падает  ag .

3

смонтировал ext4 с sync. уже минут 10 записывает эти 102 мегабайта.
только это кагбе не_тест производительности, с таким же успехом я могу и ядро собрать с slow опцией и загружаться неделю.

4

Зато чистая производительность =). Без допингов =).

А в целом да. Не стоит оно того =).

5

elve пишет:

Зато чистая производительность =). Без допингов =).

не согласен. чистая производительность должна мерится вообще без каких либо опций монтирования. ведь этот кеш и есть плюшка ext4.
и да, эти 102 мегабайта всё ещё записываются. кабы не пришлось жать Ctrl+At+SysRq+Break+U...

6 (21.08.2010 19:37:13 отредактировано mycetophylax)

Reiserfs можешь оценить? А то не уверен стоит ли переходить на ext4.

7

system-root пишет:

я не хочу рисовать графики как всеми любимый Alve, который заявил ещё чёрт знает когда что БТР рвёт всех, я просто желаю всем тестерам производительности для linux систем делать тесты, с расчётам что их кто-то повторит.

спасибо. графики пусть и в правду Алв чертит, это у него лучше получается, чем тестирование.
А можно ещё один тест? Запись туда и туда скажем 50 000 файлов? (например mercurial репозиторий FireFox'а подойдёт)

Карусель разнесло по цепочке за час
Всех известий — конец
Да, весна началась!
(всё к лицу подлецу, как родному отцу, не рассказывай, батя, и так всё пройдёт)

8

скорость записи вообще без ФС

root@asus:~# dd if=/dev/zero of=/dev/sda2 bs=1024 count=100000
100000+0 записей считано
100000+0 записей написано
скопировано 102400000 байт (102 MB), 3,04191 c, 33,7 MB/c

средняя 32.82

Reiserfs подгружалась как модуль

root@asus:/mnt# time tar xvf linux-source-2.6.32.tar.bz2
real    1m59.464s
user    0m41.989s
sys     0m7.987s

root@asus:/mnt# dd if=/dev/zero of=FILE bs=1024 count=100000
100000+0 записей считано
100000+0 записей написано
скопировано 102400000 байт (102 MB), 1,32455 c, 77,3 MB/c

средняя скорость за 10 проходов 75.7

9

Ну быстрая... Осталось посмотреть на накладные расходы и работу с большими разделами  smile

10

system-root,
Спасибо  wink . Остаюсь на reiserfs.
Если в конце концов найду время и перееду на RAID 0, повторю твои тесты.

11

zerg пишет:

Осталось посмотреть на накладные расходы и работу с большими разделами

по этому рейзер и не использую больше + проблемы при крэше ФС.. чекдиск рейзер просто форматит всё. =(

drBatty пишет:

А можно ещё один тест? Запись туда и туда скажем 50 000 файлов? (например mercurial репозиторий FireFox'а подойдёт)

скопировал исходники ядра два раза, получилось 67658 файлов и каталогов.

root@asus:/mnt# ls -R testdir/ | wc -l
67658
root@asus:/mnt#

btrfs:

root@asus:~# time cp -R testdir/ testdir2/

real    2m16.319s
user    0m0.496s
sys     0m15.526s
root@asus:~#


ext4

root@asus:/mnt# time cp -R testdir/ testdir2/

real    2m33.388s
user    0m0.475s
sys     0m10.687s

ext4 проиграл на 17.069 секунд.

при копировании с btrfs на ext4 испытывал дикие тормоза, chrome грузил процессор на 99%.
это очень странно, т.к. после копирование всё вернулось в обычный режим
почему именно chrome?

12

system-root пишет:

ext4 проиграл на 17.069 секунд.

так это немного для 2х минут в процентах. с достаточной для практики точностью - эквивалентно.

system-root пишет:

при копировании с btrfs на ext4 испытывал дикие тормоза, chrome грузил процессор на 99%.
это очень странно, т.к. после копирование всё вернулось в обычный режим
почему именно chrome?

это старый и известный глюк (а скорее множество глюков).

Карусель разнесло по цепочке за час
Всех известий — конец
Да, весна началась!
(всё к лицу подлецу, как родному отцу, не рассказывай, батя, и так всё пройдёт)

13

drBatty, замечу что при удалении каталога testdir ext4 выиграла с опережением на 50% (!)
правда это странный тест, мне никогда не захочется копировать такое количество файлов на одно и том же жестком диске.
вообще, всё это я начал, когда после загрузки на новый раздел с btrfs увидел дикие тормоза при логине или нажатии ТАБ  - где то пл секунды. (и жесткий в это время мне так подмигивал странно своим led)
очень расстраивает то что:
а) Ubuntu полностью переходит на этот тормоз коммунизма
б) Alve опять обманул народ, так же как с upstart
в) стоит задуматься почему интернет сообщество линукс так пропагандирует заведомую ложь о продуктах, которые должны стать килл фитчами именно Ubuntu.. какие то заказные статьи ей богу.

14

system-root пишет:

замечу что при удалении каталога testdir ext4 выиграла с опережением на 50% (!)

я тоже заметил: всё удалил, а лампочка мигает и мигает...

system-root пишет:

правда это странный тест, мне никогда не захочется копировать такое количество файлов на одно и том же жестком диске.

в с этого-на этот-же ФИЗИЧЕСКИЙ диск копировали? тогда тесты не корректны - я просил с нормального, современного, того, который заведомо быстрее этой сороковки.

system-root пишет:

а) Ubuntu полностью переходит на этот тормоз коммунизма
б) Alve опять обманул народ, так же как с upstart
в) стоит задуматься почему интернет сообщество линукс так пропагандирует заведомую ложь о продуктах, которые должны стать килл фитчами именно Ubuntu.. какие то заказные статьи ей богу.

а как вы ещё представляете себе рекламу в мире Свободного ПО? Добро пожаловать в реальный мир, Нео...

Карусель разнесло по цепочке за час
Всех известий — конец
Да, весна началась!
(всё к лицу подлецу, как родному отцу, не рассказывай, батя, и так всё пройдёт)

15 (21.08.2010 22:51:04 отредактировано system-root)

drBatty пишет:

в с этого-на этот-же ФИЗИЧЕСКИЙ диск копировали? тогда тесты не корректны

почему же? потому, что прибавляется скорость чтения?

drBatty пишет:

Добро пожаловать в реальный мир, Нео...

говорила же мне бабушка, не бери эту таблетку.. не бери..

16

system-root пишет:

почему же? потому, что прибавляется скорость чтения?

Нет... фишка в другом... Алгоритмы на доступ к диску - вот важный момент. То есть не удаётся замерить, кто мусорит больше. То есть бтр мог мешать на полную программу разгонять ext4 и наоборот.

17

как же бтр мог мешать, если данные копировались с ext4 на ext4?

18

zerg пишет:

Алгоритмы на доступ к диску

стоят по умолчанию. т.е. если никто не хочет записи на бтр, этот факт не влияет на погрешность.
если поставить DeadLine шедуллер, то вообще в момент копирование жесткий диск знать не захочет ничего про соседнюю ФС.

19

system-root пишет:

почему же? потому, что прибавляется скорость чтения?

скорость позиционирования. блок головок по всему диску прыгает. читают/пишут HDD на порядок быстрее, чем головка перемещается. именно потому-то SSD и быстрее - там перемещаться просто нечему.

Карусель разнесло по цепочке за час
Всех известий — конец
Да, весна началась!
(всё к лицу подлецу, как родному отцу, не рассказывай, батя, и так всё пройдёт)

20

system-root пишет:

как же бтр мог мешать, если данные копировались с ext4 на ext4?

Опа... прошу прощения... Примерещилось, что запись с бтр на ext.

21 (22.08.2010 01:22:43 отредактировано system-root)

drBatty, т.е. если делать правильный тест на скорость копирования то только с одного жесткого на другой?
но тогда мы меряем ещё и сам жесткий, а оно нам надо? ФС решает как видно из топика коммента с рейзер.

22

system-root пишет:

т.е. если делать правильный тест на скорость копирования то только с одного жесткого на другой?
но тогда мы меряем ещё и сам жесткий, а оно нам надо?

почему? как я понял, диск-то один? скорость записи на него одна, скорость чтения из источника тоже не изменяется (источник один и тот же).

Если основное время занимает позиционирование (а это именно так видимо), то просто может у вас одна ФС лежит ближе? Вот когда вы копируете из /dev/zero, так тут источник всегда один, причём бесконечно быстрый. И файл один и большой - о чём тут ФС думать? Да ни о чём - просто тупо клади байы, и всё.

system-root пишет:

ФС решает как видно из топика коммента с рейзер.

да ничего там не видно: сжатие файлов - документированная фишка Linux'а. В EXT3/4 она включается отдельно для файлов/каталогов:

A file with the `c' attribute set is automatically compressed on the disk by the kernel.  A read from this
       file returns uncompressed data.  A write to this file compresses data before storing  them  on  the  disk.
       Note: please make sure to read the bugs and limitations section at the end of this document.
<...>
BUGS AND LIMITATIONS
       The `c', 's',  and `u' attributes are not honored by the ext2 and ext3 filesystems as implemented  in  the
       current  mainline Linux kernels.    These attributes may be implemented in future versions of the ext2 and
       ext3 filesystems.

и как видно, в МОЁМ ядре ПОКА не включена. Что там у вас - без понятия. Особенно с новой ФС, которой у меня естественно нет. Кроме того, есть ещё и т.н. разряжённые файлы, их умеет делать даже команда cp. dd конечно такого не делает, но где написано, что этим не занимается ваша FS? Если, ЕМНИП, такое NTFS уже делать могла, начиная с Windows2000. В cp довольно примитивный алгоритм, так почему-бы его не улучшить? Уже на уровне ФС, учитывая, что сейчас не 2000й год, и процессоры стали намного быстрее. Не... Сначала сделайте рандомный файл (это долго, но пойдёт любой архив со сжатием), а потом уж этот рандомный файл пишите, причём с другого диска. Или можно программку написать простенькую, чтоб генерила псевдослучайные числа, а то /dev/urandom уж больно тормозная обычно (про /dev/random вообще молчу).

Карусель разнесло по цепочке за час
Всех известий — конец
Да, весна началась!
(всё к лицу подлецу, как родному отцу, не рассказывай, батя, и так всё пройдёт)