LINUX.ORG.RU

Сравнение быстродействия EXT3, EXT4, XFS, Btrfs, NILFS2

 , , , , , ,


0

1

Аналитики Phoronix.com произвели серию тестов различных файловых систем, поддерживаемых ядром Linux 2.6.30. В тестировании также участвовала новоприбывшая журнально-структурированная NILFS2, которая хорошо проявила себя в тестах Dbench и SQLite.

>>> Подробности по ссылке

★★★★★

Проверено: Shaman007 ()
Ответ на: комментарий от isden

ext4, разве что ext4 очень проигрывает ext3( и вроде NILFS ) в тесте с sqlite

lester ★★★★
()

> Аналитики Phoronix.com

ну эти, небось, сравнивали ext3 на 486-м и ext4 на core2quad, с них станется

overmind88 ★★★★★
()

Чёрт, всё руки не доходят эти с рейзерами сравнить.

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

wyldrodney
()

"Аналитики Phoronix.com" дальше не читал, правда, клянусь.

Julio_Petrovich
()

А где тег "Британские Учёные"?

pc
()

После знакомства с тестом SQLite дальше не читал.

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

>в 2-х словах, что круче оказалось?

HFS конечно. щас набигут макосники и подтвердят

registrant ★★★★★
()

>Аналитики Phoronix

ну да, ну да. до них даже британским ученым далековато

vostrik ★★★☆
()

v0.19 (Jun 2009)
v0.19 is a forward rolling format change, which means that it can read the v0.18 disk format but older kernels and older btrfs-progs code will not be able to read filesystems created with v0.19. The new code changes the way that extent back references are recorded, making them significantly more efficient. In general, v0.19 is a dramatic speed improvement over v0.18 in almost every workload.

устарело уже сравнение для btrfs )

Sylvia ★★★★★
()

Аналитики Phoronix.com те ещё тролли.

melkor217 ★★★★★
()

Опять Рейзер нет, что-то Рейзер какой-то диссидентской ФС стал...

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

Да, и иногда подстановка переменных не срабатывает:)

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

> Спасибо, видимо действительно пора уже переходить на ext4.

Могу поделиться своим опытом.

У меня gentoo, портежи и дистфайлы вынесены на отдельные разделы на reiser4.

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

Как же так, портежи на райзере занимали ~350Мб, раздел на 2 Гб. После ошибки df -h выдавал занятость раздела 1.1 Гб. Еще же 900 Мб свободно.

Отформатил в ext3, тоже самое. Подумал может журнал мешает и форматнул в ext2. Все равно заполняет на 1.1 Гб и все.

Отформатировал обратно в reiser4 и все скопировалось обратно, что со сжатием, что без.

В чем секрет? Может кто знает?

beda
()

Уже 6й год райзер на десктопе, никаких нарецаний небыло, все работает стабильно и объективно-быстро

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

> В чем секрет? Может кто знает?

в инодах. 21-век на дворе, а в ext3 (и видимо ext4) до сих пор количество инод фиксировано на этапе форматирования, как следствие кучу мелких файлов эти фс не переваривают

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

> в инодах. 21-век на дворе, а в ext3 (и видимо ext4) до сих пор количество инод фиксировано на этапе форматирования, как следствие кучу мелких файлов эти фс не переваривают

Я догадывался, что дело в inode'ах, но боялся сказать :)

beda
()

опять блатной фс нет .... :(

unisky ★★
()

Почему молчат британские учёные? Волнуйус.

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

>>>В чем секрет? Может кто знает?

>>man tail

> Ну ты понял, что это ман выдаст... :)

tail - deliver the last part of a file

DESCRIPTION The tail utility copies the named file to the standard out- put beginning at a designated place. If no file is named, the standard input is used.

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

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

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

>Спасибо, К.О.!

Нет, просто не понял, чё из этого понять-то надо было.

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

>http://web.archive.org/web/20070620025139/linuxhelp.150m.com/resources/fs-ben... Сам сижу на Reiser4, со сжатием и без, в зависимости от назначение раздела.

Непонятно почему в 2.6.20 производительно reiser4 упала чуть ли не на 50% по сравнению с 2.6.13

Как таам дела с 2.6.30?

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

> Непонятно почему в 2.6.20 производительно reiser4 упала чуть ли не на 50% по сравнению с 2.6.13

Я где-то читал, что производительность упала не только в reiser. Просто на reiser это больше всего сказалось. Насколько я помню, в ядре изменили алгоритм работы функций ввода-вывода.

Сцылку пока найти не могу.

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

> Как таам дела с 2.6.30?

У меня 2.6.29. Производительность всем устраивает, а сжатие впечатляет. Даже не самое сильно сжатие lzo ужимает около 40% /usr.

Если на reiser4 без сжатия /usr занимает 18% от размера ФС, то со сжатием lzo 10%

Делаю выводы: алгоритм lzo проще gzip2 (меньше процессорного времени на распаковку) и данных с жесткого диска считывать меньше на 40%.

Правда с /usr/portage/distfiles сжатие не проходит. Там одни архивы. Тормозит при emerge заметно сильнее, нежели без сжатия.

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

У меня раздел с сжимабельным барахлом и сорцами на btrfs+zlib. С Reiser4 возился 3 года, потом устал, старею)

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

> Пролистал тесты. Получается, что ext4 заемтно хуже, чем ext3.

ИМХО, в SQLite видна регрессия, либо какой-то эпопейный фейл в тесте. Решается LD_PRELOAD=libnosync.so sqlite3 :)

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