LINUX.ORG.RU

[вброс] сравнение скорости чтения /lib на разных фс

 


0

0

По мотивам.
Провёл сравнение скорости чтения большого количества мелких файлов на разных фс (конкретнее каталога /lib).

$ du -sh /lib
152M	/lib
После выполнения каждой операции с фс очищал кэш так:
sync; echo 3 >/proc/sys/vm/drop_caches
Измерял так(повторял несколько раз):
tar -c /mnt/1/lib/ |pipebench >/dev/null
Фс были созданы и монтировались с опциями по-умолчанию, если не указал иное.
Результаты(усреднённые):
ext2        36M/s
ext4        10.5M/s (ради лулзов пробовал mkfs.ext4 -O ^filetype,^resize_inode,^ext_attr,^has_journal - так же)
reiserfs3.6 16M/s
xfs         17.8M/s
fat32       31M/s (вот так mkfs.vfat -F 32 -S 4096 - получил 40M/s)
ЧЯДНТ, кто виноват, что делать?
Из-за какой опции ext4 так проиграла ext2(в остальных случаях ext4 быстрее)?



Последнее исправление: anon_666 (всего исправлений: 1)

Ответ на: комментарий от Led

>твой «тест» - г@#но.
Меня интересовало только чтение, и, в основном, {/usr,}/lib.

squashfs

С ней гемора больше, но собираюсь потестить.

anon_666
() автор топика
  1. Где расположен раздел? Нужно все тесты проводить на одном и том же разделе, расположенном в одном и том же месте одного и того же диска.
  2. Как на него попали файлы? На все тестовые ФС файлы заливать надо одним способом, т.е. использовать в одном тесте «реальную» копию /lib, созданную менеджером пакетов, а в остальных - созданную при помощи cp -a, нельзя.
  3. 152MB - это маловато для теста.
  4. pipebench - что это за хренота? Лично у меня даже при добавлении в конец пайпа dd of=/dev/null bs=3276800 время увеличивается в несколько раз.
Deleted
()
Ответ на: комментарий от Deleted

>Нужно все тесты проводить на одном и том же разделе
Разумеется, так и делал.

файлы заливать надо одним способом

Так и делал - копировал в каждом случае с системного раздела.

152MB - это маловато для теста

/usr/lib у меня 5G, столько свободного места на hdd нет.
Да и повторял несколько раз.

pipebench - что это за хренота?

«Спросите Silvy» ©

anon_666
() автор топика

По-моему, все правильно. Как говорится, «конец немного предсказуем».

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

Лично я корень держу на рейзере, а xfs — на разделах с данными. В ext* только хомяк и /boot (если они отдельно).

nnz ★★★★
()

[code] 2G /dev/vg1/test mounted to /mnt/fs-test

/usr/lib ~~ 1.2G copied to /mnt/fs-test find /mnt/fs-test ! -type d | wc -l 18046

sync; echo 3 >/proc/sys/vm/drop_caches tar -c /mnt/fs-test/lib/ |pipebench >/dev/null

mount -o relatime,nodiratime

xfs  — 1.08 GB in 0m33.64s: 33.12 MB/second ext2  — 1.08 GB in 0m26.66s: 41.79 MB/second ext3  — 1.08 GB in 1m13.05s: 15.25 MB/second ext4  — 1.08 GB in 1m14.96s: 14.86 MB/second reiserfs 3.6 — 1.08 GB in 1m17.37s: 14.40 MB/second

$ df -T | awk 'NF == 7 {f[$2]++}; NF == 6 {f[$1]++}; END {for(k in f) {print k,f[k]}}'

ext2 1 xfs 8 tmpfs 3

[/code]

anonymous
()
2G /dev/vg1/test mounted to /mnt/fs-test

/usr/lib ~~ 1.2G copied to /mnt/fs-test
find /mnt/fs-test ! -type d | wc -l
18046

sync; echo 3 >/proc/sys/vm/drop_caches
tar -c /mnt/fs-test/lib/ |pipebench >/dev/null

mount -o relatime,nodiratime 

xfs          -- 1.08 GB in 0m33.64s:   33.12 MB/second
ext2         -- 1.08 GB in 0m26.66s:   41.79 MB/second
ext3         -- 1.08 GB in 1m13.05s:   15.25 MB/second
ext4         -- 1.08 GB in 1m14.96s:   14.86 MB/second
reiserfs 3.6 -- 1.08 GB in 1m17.37s:   14.40 MB/second



$ df -T | awk 'NF == 7 {f[$2]++}; NF == 6 {f[$1]++}; END {for(k in f) {print k,f[k]}}'

ext2  1
xfs   8
tmpfs 3

anonymous
()
Ответ на: комментарий от Ximen

>На туче мелких файлов XFS и скорость несовместимы.

Да, забыл это упомянуть. Пожалуй, основная причина, по которой у меня корень обычно на рейзере.

anonymous
()
Ответ на: комментарий от x3al

ФС на LVM уже поддерживает барьеры?

anonymous
()
Ответ на: комментарий от devl547

А как там у нас с фрагментацией и возможностью изменения размера раздела? Не троллинга ради. Когда использовал эту ФС, изменить размер раздела было невозможно и в некоторых обзорах было упоминание о не слабой фрагментации при длительном использовании.

partyzan ★★★
()
Ответ на: комментарий от partyzan

у reiser4 - да, это единственная проблема. И это надо Шишкина пихать, может что и придумает.
у btrfs такой проблемы нет)

devl547 ★★★★★
()
Ответ на: комментарий от guilder

jfs также уныла как и ext3/4 с рейзером

jfs — 1.08 GB in 1m09.30s: 16.08 MB/second

anonymous
()
Ответ на: комментарий от anonymous

>xfs  — 1.08 GB in 0m33.64s: 33.12 MB/second

Хм, как была создана фс?
Видимо, у меня она отработала хуже, из-за того, что монтировал без noatime, nodiratime.

anon_666
() автор топика
Ответ на: комментарий от anon_666

> как была создана фс?

Все ФС создавались дефолтно mkfs.$FS /dev/vg1/test

anonymous
()

лично у меня чтение /lib64 на reiserfs доходит до 27 Мб/сек, потом данные просто кончаются

попробуй с бОльшим каталогом

anonymous
()
# du -sh /usr/lib
2,2G	/usr/lib

# sync; echo 3 >/proc/sys/vm/drop_caches
# tar c /usr/lib |pipebench >/dev/null
...
Piped    2.09 GB in 00h01m12.08s:   29.82 MB/second
# mksquashfs /usr/lib /111.sqfs -no-xattrs
...
# ls -lh /111.sqfs
-rw-r--r-- 1 root root 664M Окт 25 08:39 /111.sqfs

# mount -t squashfs -o loop /111.sqfs 1/
# sync; echo 3 >/proc/sys/vm/drop_caches
# tar c 1/ |pipebench >/dev/null
...
Piped    2.09 GB in 00h00m37.46s:   57.38 MB/second

/usr/lib и сжатый образ находились на одном разделе размером ~5.7G, так что геометрия диска практически не повлияла на результаты.

anon_666
() автор топика
Ответ на: комментарий от nnz

у нее есть проблемы с целостностью данных при отключении питания

Если бы только это, то была бы идеальная ФС. Главная проблема — скорость при обработке большого количества объектов: копирование нескольких тысяч мелких файлов (тема иконок это была) шло настолько медленно, что можно было пойти прогуляться (а в сумме это всего лишь около 50Мб). Простора для тюнинга тоже не оказалось — в Дебиане mkfs.xfs по умолчанию создаёт ФС с предельными параметрами. Разве что с количеством AG's можно поиграться, но это не должно оказать особого влияния на такие случаи %)

GotF ★★★★★
()
Ответ на: комментарий от anonymous

ext4 даже ex3 слил, правда в районе погрешности.

unikum ★★★★★
()

реквествую btrfs в тесты:)

unikum ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.