Тенденция?

В 9-CURRENT внедрена ZFSv15

Новая версия отличается проведением работы по исправлению ошибок, оптимизиацией производительности (тесты показывают прирост скорости на 15-20%) и добавлением поддержки пользовательских и групповых квот.

Позднее планируется полная миграция на версию ZFS 24, в которой реализована поддержка автоматического распознавания и объединения дубликатов данных. Если в нескольких файлах присутствуют аналогичные блоки данных, то они будут сохранены на физический носитель только один раз, что позволит существенно уменьшить потребление дискового пространства и увеличить производительность - вместо копирования блоков будет лишь изменена запись в соответствующей таблице.

Btrfs ещё не впродакшене и не имеет среди своих фич поддержку RAID-5 и -6, а только RAID-1(0).

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

> Что лучше: отлаженная фичастая ФС, у которой осталось оттюнить алгоритмы, или быстрая сырая ФС без реализации основных фич, жизненно необходимых для продакшена?

Еще раз - сравнивались не файловые системы, а непонятно что непонятно с чем непонятно какими тестами, которые непонятно какое отношение имеют к тестируемым сущностям.

Помнится, ты же сам говорил, что по умолчанию в generic ядре FreeBSD повключено много всего лишнего.

> Был неприятный тред на lkml, в котором Эдуард Шишкин высказал некую обоснованную критику в адрес btrfs. Там была какая-то проблема со свободным местом. Никто не помнит, чем там все закончилось?

Там всё достаточно интересно. Оказывается, Крис Мейсон захотел преимуществ reiserfs не зная, как работают её алгоритмы. А в рейзере нет B-деревьев, там совсем другие структуры данных, о которых, похоже, никто не знает и которые не приспособлены к балансировке «сверху вниз». Вот и полезла у Криса фрагментация. В последнем письме Шишкин предложил алгоритм для btrfs, вроде как правильный.

+ может используемый размер блока по умолчанию (128кб) дает о себе знать

Помнится, ты же сам говорил, что по умолчанию в generic ядре FreeBSD повключено много всего лишнего.

Да, там debug-информация во весь рост понавключена.

А если еще и сжатие использовать в btrfs...

про стабильность бы почитать.

а что, на «протестить» скачать нельзя уже? вроде по http://www.oracle.com/technetwork/server-storage/solaris/downloads/get-jsp-13... вполне себе доступна.

про спарки и интелы - это Вы уже придумываете.

> + может используемый размер блока по умолчанию (128кб) дает о себе знать

Может быть. Хер знает как там этот их тестовый набор работает.

>Btrfs ещё не впродакшене и не имеет среди своих фич поддержку RAID-5 и -6

Насколько я помню, ZFS не умеет увеличивать размер raid5/6-томов. Т.е. поддержка этих уровней рейда в ZFS тоже не готова для продакшена.

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

Намекаешь, что из UFS2+GEOM и ZFS админ выберет отлаженную фичастую UFS2?

>А почему ZFS на FreeBSD, а не на Solaris? Не очень обективные критерии, ext4 для ubuntu - ето нативная FS, а ZFS для FreeBSD - нет. Таким образом, подобрав нужние ОС можно доказать что угодно.

Потому что тут любят утверждать, что во Фря полна замечательных и быстрых ФС. А линукс тормозит на IO.

Как-то так...

> 12309 уже починили?

А его никогда и не было. Это - миф, оправдание тех, кто не умеет сам настраивать нужные параметры, и неосилил поставить прогу, которая сделает это за них.

apt-get install irqbalance

В нормальных дистрах установлено по-дефолту.

> Никто не помнит, чем там все закончилось?

На ЛОРе закончилось этим:

http://www.linux.org.ru/jump-message.jsp?msgid=5041798&cid=5055700

В LKMLе закончилось примерно тут:

http://kerneltrap.org/mailarchive/linux-btrfs/2010/7/9/6885054

УМВР.

Намекаешь, что из UFS2+GEOM и ZFS админ выберет отлаженную фичастую UFS2?

Если админу не нужны дополнительные возможности от ФС, например, сквозная верификация данных, нефиксированные размеры файловых систем, то, действительно, лучше обходится простыми ФС, которые давно проверены и работают по принципу «поставил и забыл». Тем более, в UFS2 не такой зверский fsck, как в ZFS, — проверка дисков в фоне после аварии займёт весьма незначительное время.

> - btrfsck не умеет чинить btrfs, только сообщает об ошибках (если они есть). Помогает только backup-mkfs-restore.

Это ужасно, вообще-то. И часто ты делаешь backup-mkfs-restore, мучаясь с этой btrfs? Виндузятники значит винду периодически переинсталлируют, а мы будем то же самое с линуксом делать из-за btrfs...

> Что лучше: отлаженная фичастая ФС, у которой осталось оттюнить алгоритмы, или быстрая сырая ФС без реализации основных фич, жизненно необходимых для продакшена?

Лучше ZFS под FreeBSD, потому что под линухом жизнь - это бесконечное тестирование глюкодрома на хомячках.

Часто. Уже два раз за год. Правда - оба раза после экспериментов в стиле ССЗБ: включил async и через несколько дней был blackout (электричество отключили).

>а что, на «протестить» скачать нельзя уже?

а зачем? смысл качать на «потестить»? Чтобы потом дебиловатые отродья качали на «поработать» пока не поймали?

Лично мне не интересны сравнения с системами, которые я все равно не буду испльзовать в силу их закрытости и недоступности на законных основаниях.

> Лично мне не интересны сравнения с системами, которые я все равно не буду испльзовать в силу их закрытости и недоступности на законных основаниях.

Специально для глухих - OpenSolaris доступен свободно на законных основаниях

Ок, спасибо. Надо таки дотянуться и почитать.

Дай угадаю! Новость не читал? Даже до второго слова?

>Специально для глухих - OpenSolaris доступен свободно на законных основаниях

Это временно. Собственно, возьми и сравни, если тебе интересен именно опенсолярис.

>Это временно.

Нет в этом мире ничего постоянного.

Собственно, возьми и сравни, если тебе интересен именно опенсолярис.

Сравнивать будет смысл, когда BTRFS признают пригодной для широкого использования и она обзаведется всеми необходимыми мне возможностями.

>>Насколько я помню, ZFS не умеет увеличивать размер raid5/6-томов.

плохо у вас с памятью...
http://www.c0t0d0s0.org/archives/6224-You-dont-need-zfs-resize-...-and-a-work...

>Нет в этом мире ничего постоянного.

при всем при этом бздю и линукс всегда можно взять и поставить в работу без нарушений.

Сравнивать будет смысл, когда BTRFS признают пригодной для широкого использования и она обзаведется всеми необходимыми мне возможностями.

как и zfs..

>как и zfs..

http://www.linux.org.ru/news/opensource/4048944

надо помнить что у FreeBSD не так хорошо с disk I/O как в linux

IMO имело бы смысл тестировать FS на md (memory disk) устройстве

в который раз убеждаюсь что linux не хватает здорового консерватизма, а FreeBSD коммиттеров

надо помнить что у FreeBSD не так хорошо с disk I/O как в linux

Да-да, во FreeBSD не воспроизводится «bug 12309» из Linux.

> при всем при этом бздю и линукс всегда можно взять и поставить в работу без нарушений.

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

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

как и zfs..

В btrfs есть всего одна фича, которой пока нет в ZFS - это удаление устройств и уменьшение размера. Но, во-первых, мне это нафиг не надо, а во вторых в btrfs эта фича еще толком не работает, так что можно считать, что ее нет.

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

> надо помнить что у FreeBSD не так хорошо с disk I/O как в linux

надо помнить, что изрядная доля тестов у пхороникса не имеет к тестированию файловых систем никакого отношения. Например, тест compress-gzip измеряет время сжатия предварительно (прямо перед сжатием) созданного файла из нулей размером 2GB. На системе с 4GB RAM этот файл будет в кэше, а никаких мер по очистке кэша у них не простматривается. Так что это тест чего угодно, но только не файловой системы. С Threaded IO Test'ом тоже не все однозначно. Вообще, нахер было надо изобретать какую-то херню, когда есть filebench..

IMO имело бы смысл тестировать FS на md (memory disk) устройстве

такое тестирование тоже бы имело крайне мало общего с реальным использованием файловых систем в жизни

А давайте еще тестить используя фсе фичи, например zfs с выделеным кешем на ssd, zil логом на отдельных девайсах и т.д. и это есть уже сейчас и работает, а btrfs в глубокой альфа версии

> Дайте угадаю! Фороникс?

Что-то последнее время много на LORе возражений типа «Фороникс такой Фороникс». Может причина в том, что те, кого не устраивают результаты, которые показала их любимая система, пытаются таким способом заставить других в них не верить? Но на тесты нужно возражать тестами. Если нет ссылки на альтернативный тест, в котором результаты получаются совершенно иные, то почему нужно сомневаться в результатах с phoronix.com? Ситуация выглядит так: есть результаты тестов, есть недовольные, но нет заслуживающих внимания возражений...

> Что-то последнее время много на LORе возражений типа «Фороникс такой Фороникс». Может причина в том, что те, кого не устраивают результаты, которые показала их любимая система, пытаются таким способом заставить других в них не верить?

Дело не в этом. Дело в том, что тесты фороникса очень часто не имеют отношения к тому, что тестируется. Пример - тест compress.gzip из этого тестирования.

> Дело не в этом. Дело в том, что тесты фороникса очень часто не имеют отношения к тому, что тестируется. Пример - тест compress.gzip из этого тестирования.

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

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

>> и отходит на второй план

она уже давно там:

http://w3techs.com/technologies/details/os-unix/all/all

примичательная цифра - «95% используют линукс», а BSD - 3

> А разве это не является тестом файловой системы при загруженном процессоре? Результат зависит в том числе и от того, насколько работа с файловой системой нагружает процессор. На первый взгляд это вполне нормальный тест.

А подумать? На системе с 4 гигабайтами ОЗУ файл размером в 2 гигабайта целиком поместится в памяти. Соответственно, читать с диска скорее всего не придется ничего.

Конечно, результаты теста могут несколько отличаться, в зависимости от того, когда система начнет таки сбрасывать грязные страницы на диск - если это произойдет в тот момент, когда gzip сжимает файл, это явно отожрет у него часть ресурсов. Но каким образом на основании этого ты будешь судить о производительности файловой системы?

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

>как бы этот тест на убунту проводился, где выбор btrfs при установке уже есть в 10.10

Машина времени? Октябрь ещё какбэ не наступил, поэтому «уже есть» - немного спорный вариант. А вот в приведённом мной примере уже есть, в отличие от. Причём в боевом режиме сделал btrfs корневой фс на одной из виртуалок.