LINUX.ORG.RU

Сравнение быстродействия нативного порта ZFS и Ext4/BtrFS/XFS в Ubuntu 10.04 LTS

 , , , , , ,


1

1

Аналитики Phoronix.com произвели серию тестов различных файловых систем в Ubuntu 10.04. Для поддержки файловой системы ZFS в Ubuntu 10.04 LTS использовался модуль разработанный компанией KQ Infotech. В отличие проекта разрабатываемого по заказу LLNL модуль KQ Infotech поддерживает ZFS Posix Layer (ZPL), поэтому можно работать с файлами с помощью обычного файлового менеджера.

Вот какие результаты были получены:

  • В тесте Apache Benchmark v.2.2.11 самой производительной оказалась Ext4, а ZFS самой медленной
  • SQLite v.3.6.19 самой производительной оказалась XFS, а ZFS самой медленной Правда ZFS в OpenIndiana b147 показала бо́льшую производительность чем XFS в Ubuntu 10.04 LTS
  • В тесте Compile bench v.0.6 на сей раз самой производительной оказалась Ext4, чуть отстала Btrfs, предпоследние место заняла ZFS, а самую худшую производительность показала XFS. ZFS в OpenIndiana b147 показала производительность меньше чем Btrfs, на больше чем ZFS в Ubuntu 10.04 LTS
  • В тесте I/O Zone v.3.347 при размере файлов 64k лучшую производительность показала Btrfs, а худшую ZFS
  • В тесте I/O Zone v.3.347 при размере файлов 4k теперь ZFS на втором месте, Btrfs снова в лидерах, а на последнем месте оказалась XFS
  • В тесте FS-Mark v.3.3 в лидерах Ext4, на втором месте ZFS, а Btrfs показала худший результат
  • В тесте Threaded I/O Tester v.0.3.3 теперь в лидерах ZFS, Btrfs показала чуть худший результат, а на последнем месте оказалась Ext4

>>> Подробности

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

не надо вырезать из контекста мою фразу

1- в принципе не имеют значения для загрузки системы, когда грузится ось и автозагрузка - ибо в этот момент никто еще ничего не делает

или мы как то можем смотреть фильмы и качать их, когда ось еще не загрузилась?

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

>не надо вырезать из контекста мою фразу

Хорошо, это ответ на «еле заметно сказываются на скорости работы системы» - от этого ничего не изменится.

...

Кстати, фрагментация системного раздела сильно сказывается на скорость загрузки. И под Windows, и под Linux. Разница между сильно запущенными и оптимизированными вариантами может быть почти двукратной. 20 секунд загрузки или 40 - достаточно заметная разница :)

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

>Тогда как тот мсье бы объяснил отсутствие фрагментации и тормозов в свете

Кодировку бы сперва починили там.

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

>Кстати, фрагментация системного раздела сильно сказывается на скорость загрузки. И под Windows, и под Linux. Разница между сильно запущенными и оптимизированными вариантами может быть почти двукратной. 20 секунд загрузки или 40 - достаточно заметная разница :)

МЕССИЯ В ТРЕДЕ!

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

по поводу кодировки на форуме есть фак, где написана причина сего действа. Я конечно понимаю, что это ЛОР, но ручками разок выставить кодировку на этой странице не судьба? или это неправославно?

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

> Скажу иначе - если на нагруженном сервере начинает вообще влиять дисковая подсистема, то он будет тормозить что с фрагментацией, что без неё.

Полностью согласен! Когда начитаются проблемы, гораздо эффективнее нарастить дисковую подсистему. Тем более сейчас, когда появились доступные SSD вроде Intel X25-E...

Сделайте дефрагментацию майлдиров. Эффект удивит

У меня mbox'ы :).

Спасибо за интересную дискуссию.

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

>напомню, что большинство p2p клиентов сразу выделяют место на диске. имя твоего клиента ффстудию!

Valknut. Ведовый strongdc тоже это умеет.

если ты хранишь файло на системном диске и постоянно обновляешь ПО - то да, но каким же надо быть красноглазиком, чтобы хранить систему и мультимедиа на одном разделе?

В обоех случаях - это старое Г. с дисками по ~40Гб. Не вижу смысла ставить нормальное желез для просмотра SD видео.

такой, к.ней, как программный рейд, лучше не заниматься. Поростешь, устроишься на работу в какую либо более-менее солидную фирму IT (хотя без блата ТЕБЯ туда не пустят) - вот и увидишь, что НИКТО не юзает программные рейды, только аппаратные с недешевыми контроллерами

У меня своя it компания. И доказываю я тебе тут что-то, только от скуки. В принципе, мне всё-равно, какие ты выводы сделаешь.

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

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

>хотя да, согласен. Тогда как тот мсье бы объяснил отсутствие фрагментации и тормозов в свете http://wl500g.info/showthread.php?t=12452

Там про весьма неоднозначную ext3 (насколько я понял с поломанной кодировкой). Ты накопай что-нибудь про reiserfs, ext4 или xfs, тогда поговорим.

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

>NTFS я использовал, начиная с Windows 3.11 на многих десятках (а, может, и сотнях - не считал точно, но сотни машинолет - уже точно) машин в самых жёстких условиях (тупые юзеры, постоянно жмущие reset'ы, отключения питания и т.п.). И ни разу она у меня не падала.

O_O Win3.11 поддерживает нтфс? Ее вроде даже 98 не поддерживала.

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

>А для старых ФС, таких как ext3 и reiserfs, дефрагментаторы не нужны.

Не соглашусь. Я юзал одно время торент на рейзеровском разделе. Сначала все было хорошо, скорости хорошие - но через некоторое время скорость упала до неприличных величин. Да и тот же XFS, хотя лучше всего справляется с фрагментацией (из за отложенной записи), начинает тормозить когда место на винте кончается. В особо клинических случаях, когда место кончается под ноль, невозможно войти в каталог, приходится минуты ждать. Я решил эту проблему, поставив в рторенте ограничение на скачивание, когда место на диске падает ниже 10 Гб (на 320 гиговом разделе).

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

Сделайте раздел под торент, форматните ее хоть в рейзерфс, хоть в XFS. Поюзайте месяцок, забейте под завязку несколько раз, удаляйте закачки, создавайте новые - а потом попробуйте сделать дефрагментацию (тупо mv на другой раздел - makefs - mv обратно). Почуствуйте разницу.

не заполнять больше чем на 80%"...

Этот совет актуален и для XFS (думаю что и для остальных, просто я их юзал меньше и точно не могу сказать). Правда, 80% перебор, вполне хватит 95%.

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

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

>Ради эксперимента, сделай копию файла в 1гб и копии 100 000 файлов по 10 кб на одном разделе с ехт, а затем на нтфс - и засеки время копирования. Будешь очень удивлен. И в завершении попробуй сделать то же самое еще раз, но выруби питание в середине операции.

Не знаю насчет ext3, возможно ntfs и выиграет (ext3 тормоз еще тот) - но вот рейзер наверняка натянет ntfs.

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

Там внизу приписочка о полезности фата. А вообще статься о полезном неофициальном способе лечения некой кривой оси, для которой и были разработаны некоторые ФС. Если иметь способ оживлять её множество раз, то можно собрать приблизительную статистику о том какая из двух ФС при некошерном использовании надёжнее. А какая надёжнее, уже говорил, могу добавить про то, что большинство пользователей не собирается обзаводиться бесперебойником, а перегрев и зависания приводят сам знаешь к чему. Статья древнющая, статистика в ней если и использована то мало, её можно дополнить несколькими предложениями: Линуксовый лайфсиди помогает при редактировании файлов и спасения фоток. После установки сервиспака старый реестр становится несовместимым с новым. Для сохранения совместимости старого реестра с новым, автоматическое обновление нужно отключить, обновлять вручную и после этого делать новую копию реестра.

ЗЫ. Тучи сгущаются над этой темой, существует опасность потухания звезды. Посему, если хочешь задать вопрос, лучше сделай это на форуме.

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

>собственно, это так, но что мы обычно делаем с мультимедиа? слушем (300кб.с), смотрим двд (1мбайт/с), качаем (1-3мбайт/с,10 в случае локалки) - такие скорости - 1- в принципе не имеют значения для загрузки системы, когда грузится ось и автозагрузка - ибо в этот момент никто еще ничего не делает, 2 - еле заметно сказываются на скорости работы системы.

ДВД прошлый век, HDTV рулит. Там скорости уже другие, вплоть до 10 метров в сек. Это уже вполне сравнимо со скоростью чтения с фрагментированного раздела. А если в фоне еще и закачки всякие, компилирование-копирование-архивация, то тормоза не просто очень вероятны, они почти неизбежны.

zsh
()

Что то мне после этого треда пришла в голову мысля дефрагментировать торентовский раздел (до этого несколько месяцев юзался, постоянно что-то качаю-удаляю), так вот, фрагментация очень сильно заметна: те фильмы которые скачаны давно (т.е. на почти пустой винт) качаются со скоростью 40 и больше метров в секунду, те которые недавно - 15-20. И удаление всех файлов (282 гб) заняло 40 (!!!) минут. А обратно, уже на пустой винт, скорость записи 50-60 метров в сек. Фильм 40 гб удалился за 1.3 сек. Почувствуйте разницу, так сказать.

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

Ах да забыл сказать. Копию каталога я делал на отдельный диск на котором тоже XFS. Потом этот каталог с него снес - заняло это секунд 15 (не засекал, так на глаз). Сравните с 40 минутах на фрагментированном диске.

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

>А, ясно :)

Кстати, а вот уже Win9x поддерживала. Правда, через приложение ручек и стороннее решение, которое юзало .dll-ки от NT :)

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

> Кстати, фрагментация системного раздела сильно сказывается на скорость загрузки. И под Windows, и под Linux. Разница между сильно запущенными и оптимизированными вариантами может быть почти двукратной. 20 секунд загрузки или 40 - достаточно заметная разница :)

А если readahead установлен и настроен? В linux это легко проверить bootchart-ом. На нем обычно хорошо видно, что I/O занимает при загрузке не так много времени...

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

>А если readahead установлен и настроен?

Он в этом смысле помогает, но не сильно.

На нем обычно хорошо видно, что I/O занимает при загрузке не так много времени...


Вот на сильно фрагментированной системе этого IO станет много больше :)

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

> а здесь можно поподробнее - это что за характеристика фс «эффективность хранения файлов на диске»?

Например, reiser-ы позволяют занимать файлу меньше одного кластера. Место не теряется из-за полупустых кластеров.

за 5 лет любой мало-мальски нормальный спец меняет себе дома железо по полной.

Далеко не все железо. Винт, например, отлично переезжает из одной системы в другую. Не переустанавливать же всю систему просто из-за того, что сменилась видеокарта? Даже если меняется винт - нет смысла переустанавливать ОСь, делается dd раздела. А лет пять назад состоялся переход на 64-битную систему, и тогда-то систему пришлось установить с нуля.

ты сделал вывод о приросте скорости

Это была ирония. Если все-таки ЧИТАТЬ сообщения, на котороые пишешь ответ, то в оригинальном сообщении можно обнаружить смайлик, а в следующем за ним - обоснование ускорения (про новый initrd, новые ядра, upstart вместо классического init-а и т.д.). Речь шла только о том, что система, очевидно, фрагментируется, особенно после такого числа обновлений, а скорость НЕ ПАДАЕТ.

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

Не надо судить по себе о всех остальных.

если 5 лет назад хватало всем 512 оперативы, то теперь меньше чем с гигом лучше не сидеть

Два гига. Да, иногда не хватает. Докуплю как-нибудь. Слоты есть. Линукс - 64-битный, съест и не заметит, а винда... черт с ней, сколько увидит, столько и увидит.

мда... ты еще /tmp и /var докинь в коренной раздел...

Они итак там. Даже объясню, почему. Например, потому, что mc при копировании с какого-нибудь ftp-шника, сначала копирует в /tmp (/tmp/mc-username видел?). И я не хочу, чтобы при копировании гигового файлика он сожрал гиг оперативки. А еще, внезапно, при просмотре флешевых роликов сам ролик тоже закачивается в /tmp и когда этот ролик - на пол гига, ничего хорошего в том, что он займет пол гига памяти тоже нет.

Такие вот «умники» монтируют все в tmpfs, забивают память до упора, а потом орут, что у них 12309...

Итак, вот аргументы, почему держать их в корне - удобно. А будет ли хоть один аргумент против этого? Или ты только услышал, что вешать все на отдельные разделы и в tmpfs - это круто, а своих мозгов нету?

Конечно, у меня не один раздел. Я не вижу ничего плохого в отдельном разделе под торренты или игры. Но выделять разделы под var, usr или home на домашней машине - зачем?

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