LINUX.ORG.RU

Btrfs готова в продакшн

 ,


0

3

Крис Мейсон (Chris Mason), создатель и главный архитектор файловой системы Btrfs, прокомментировал появившиеся в прессе домыслы о том, что основные разработчики Btrfs не считают данную ФС стабильной, несмотря на её готовность для промышленного применения в дистрибутивах Oracle 7 и SUSE 12 (в RHEL 7 ФС Btrfs отмечена, как технология для ознакомления). Крис считает, что Btrfs уже является стабильной файловой системой, но добавляет, что несмотря на это данная ФС ещё интенсивно развивается, поэтому не все возможности готовы для промышленного применения. В частности, ещё предстоит доработать встроенную в Btrfs реализацию RAID 5 и 6. Тем не менее данная практика добавления новшеств не является чем то особенным, подобные экспериментальные возможности добавляются и в Ext4 и XFS, но не включаются по умолчанию (как и в Btrfs).

По поводу применения Btrfs по умолчанию в SUSE Linux Enterprise 12, Крис отметил, что компания SUSE является одним из активных участников разработки как компонентов ядра, так и пользовательских утилит Btrfs, поэтому отлично понимает, какие возможности можно предоставлять пользователям, а какие нет. Например, по уровню производительности в нагрузках, свойственных СУБД, Btrfs пока отстаёт от Ext4 и XFS, поэтому SUSE не рассматривает Btrfs как панацею и рекомендует клиентам наиболее оптимальные решения для разных видов приложений (в SUSE Linux 12 ФС Btrfs используется по умолчанию для системных разделов, для разделов с данными рекомендуется XFS). Интерес вызывают причины отключения в SUSE Linux 12 по умолчанию поддержки сжатия данных в Btrfs, Крис Мейсон считает данные возможности стабильными и ждёт пояснений от SUSE о причинах такого решения и готов способствовать устранению проблем, если такие имеются.

Другие разработчики также придерживаются мнения о стабильности Btrfs, что подтверждает совершенное в августе этого года удаление из кода утилит Btrfs флага, сигнализирующего об экспериментальном характере ФС. Аналогичные предупреждения о нестабильности дискового формата Btrfs были убраны из кода ядра Linux ещё в 2013 году.

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

русская языков не знаешь. стыдно должно быть

не стыдно, русачий суржик не нужен

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

А я желаю Btrfs быстрой и безболезненной смерти.

First they ignore you, then they laugh at you, then they fight you, then you win.

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

А я желаю Btrfs быстрой и безболезненной смерти.

First they ignore you, then they laugh at you, then they fight you, then you win.

Ганди говорил о победителях. Станет ли Btrfs победителем - вопрос открытый.

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

Станет ли Btrfs победителем - вопрос открытый.

Других претендентов на это место пока не видно.

Btrfs находится в статусе «будущего файловых систем в Linux» уже несколько лет, толку-то с этого. И почему XFS, которая дефолтная в RHEL - не претендент?

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

Btrfs находится в статусе «будущего файловых систем в Linux» уже несколько лет

И что? Тебе нужно, чтобы сразу после объявления сабжа будущим файловых систем все мгновенно на него переехали? Какие-то совсем уж детские аргументы в ход пошли.

И почему XFS, которая дефолтная в RHEL - не претендент?

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

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

Жор оперативки легко ограничить в zfs

То-то я никак не мог этого сделать. Поначалу-то оно вроде ест в пределах лимита, но потом преспокойно вылезает из него и жрёт дальше.

И да, я всё ещё не вижу сколько там занимают метаданные у ZFS.

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

Поначалу-то оно вроде ест в пределах лимита, но потом преспокойно вылезает из него и жрёт дальше.

Это не так, кэш zfs всегда строго в рамках zfs_arc_max.

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

Станет ли Btrfs победителем - вопрос открытый.

Других претендентов на это место пока не видно.

Btrfs находится в статусе «будущего файловых систем в Linux» уже несколько лет

И что?

И пофиг, что сейчас других претендентов не видно.

И почему XFS, которая дефолтная в RHEL - не претендент?

Потому что не умеет всего того, что умеет Btrfs. И да, всё, что умеет Btrfs - нужно.

Видимо, оно нужно не всем.

жить без функциональности Btrfs, равно как можно жить без зубной щётки и нижнего белья

О вау. Ну тогда конечно, Btrfs всех зарулит. Куда ж мы без нижнего белья, в самом-то деле.

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

Только вот реализация этого cow может быть разная

Ксатати, довольно забавно написано в педивикии -
про ZFS:
«Зная, как именно расположены данные на дисках, ZFS способна обеспечить высокую скорость доступа к ним, контроль их целостности, а также минимизацию фрагментации данных.»

Про BTRFS:
«Недостатки.При большом количестве перезаписей случайных фрагментов файлов возникает фрагментация (из-за copy-on-write)»

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

И пофиг, что сейчас других претендентов не видно

Видимо, оно нужно не всем

Продолжай держать нас в курсе. Можешь даже отписать в SUSE и Facebook, чтобы услышали твоё ценное мнение.

Ну тогда конечно, Btrfs всех зарулит

Да уже заруливает, бгг.

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

Это не так.

Это так, ибо у меня уже два десятка серверов переведены на zfsonlinux и я отлично знаю как это работает на практике.

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

А у меня оно постоянно вылазило за пределы. Так что я тоже убедился как оно «работает» на практике.

Впрочем, вопрос выбора между Btrfs и ZFS давно не стоит - между недопиленной ФС в ядре и жирным инородным уродцем я выбрал первое.

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

Продолжай держать нас в курсе.

За меня Redhat справится.

Btrfs всех зарулит

Да уже заруливает, бгг.

Что-то изменилось за 28 минут с момента

Других претендентов на это место пока не видно.
pedobear (29.10.2014 16:03:11)

и Btrfs уже не претендент, а победитель? Ну окей.

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

А у меня оно постоянно вылазило за пределы.

Возможно какие то дистроспецифичные проблемы. Я использую ubuntu server 12.04 и 14.04 x64.

жирным инородным уродцем

Слова, слова.

King_Carlo ★★★★★
()
Последнее исправление: King_Carlo (всего исправлений: 1)
Ответ на: комментарий от King_Carlo

Жирный - потому что жрёт оперативку.

Инородный - потому что не в ядре, использует свои костыльные механизмы для кэширования.

Уродец - потому что имеет упоротую плохо продуманную архитектуру (какая-то дурная логика работы с клонами/снапшотами, не умеет отключать CoW, также если включил дедупликацию - отключить её можно только полным реинсталлом ФС).

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

Это я ещё не стал упоминать вшитую в ZFS систему работы с Samba, лол.

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

дурная логика работы с клонами/снапшотами

Наиболее логичная и удобная система.

не умеет отключать CoW

На zfs не нужно отключать cow даже при работе с БД.

King_Carlo ★★★★★
()
Последнее исправление: King_Carlo (всего исправлений: 1)
Ответ на: комментарий от King_Carlo

Наиболее логичная и удобная система

Наиболее логичная и удобная система - это как раз у Btrfs, где всё есть subvolume. А не так, что целая россыпь сущностей и клон можно сделать только со снапшота.

На zfs не нужно отключать cow даже при работе с БД

Не «не нужно», а «невозможно», поэтому чтобы хвалёная ZFS не тормозила аццки на БД, приходится использовать гору и маленький холмик костылей.

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

Ну, большинство людей убеждены, что это нереально плохо и за это надо расстреливать.

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

По логике оракла сначала идёт «не нужно» и лишь как следствие «невозможно». У меня нет причин не доверять ораклу.

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

Не «не нужно», а «невозможно», поэтому чтобы хвалёная ZFS не тормозила аццки на БД, приходится использовать гору и маленький холмик костылей.

а лучше бы ты мозг использовал, дурная логика у zfs видите ли, хыхы. примеры костылей будут или так же как и с «не работающим» zfs_arc_max?

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

Нет, не нужно - это как раз CoW на БД. А то, что Оракл выкатил костыльные решения для обхода этой проблемы - всего лишь хорошая мина при дефекте в дизайне.

У меня нет причин не доверять ораклу

У адептов ZFS вся аргументация рано или поздно упирается в горячее доверие Партии Ораклу. Nuff said.

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

В сравнении с отключением CoW одной опцией монтирования - да.

Ты думаешь отключив cow у тебя автоматом всё будет просто летать? ну-ну.

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

У хейтеров ZFS вся аргументация рано или поздно упирается в горячее недоверие, что оппонент умеет пользоваться гуглом )

King_Carlo ★★★★★
()

Не понял, могу я создать btrfs поверх нескольких разделов, как в lvm?

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

Аргументно. БД хорошо уживаются с CoW? Досвидос.

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

вопрос выбора между Btrfs и ZFS давно не стоит

это точно! zfs - просто работает, а btrfs - только делает вид что может.

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

жесть.

Я тоже так считаю, но есть альтернативные мнения )

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