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 году.

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

фонната ZFS

Звучит как фанат молотка и вооон той стаместки. Какой фанатизм? Это просто хороший, годный инструмент.

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

вот прям по мановению волшебной палочки. и пофиг, что размер блока базы меньше, чем у фс, и пофиг что есть ещё 100500 условий, от которых зависят настройки конкретного сервера. посонам в школе рассказывай такие сказки.

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

Не-фоннаты не отрицают изъянов в своих инструментах, а у вас ZFS божественна с какой стороны ни зайди, лол.

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

Если ты не заметил (а ты не заметил, ибо глаза застилает обидка ипаная), то я про скорость Btrfs на БД ничего не говорил. Я сказал лишь, что CoW негативно влияет на скорость работы с БД, вот и всё. Прежде чем бросаться грудью на амбразуру, нужно хотя бы разобраться в словах собеседника, подован.

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

А кто-то забивает гвозди микроскопом

Плохая аналогия. На файловой системе я храню файлы, использую, так сказать, по прямому назначению.

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

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

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

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

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

Напряги своё вместилище маркетингового буллшита Оракла и подумай, к чему приводит частая перезапись на CoW-ФС.

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

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

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

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

видать совсем не алё в теме или упёртый как баран, ну или всё сразу :)

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

Нашел, что у badoo юзается btrfs. Надо кастовать бадушников

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

совсем не алё в теме или упёртый как баран, ну или всё сразу :)

И это очевидно.

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

CoW негативно влияет на скорость работы с БД

А вот это совсем не очевидно и требует для доказательства кучи тестов на различных конфигах стораджей. Основываясь на собственном опыте могу предположить, с большой долей вероятности, что cow-fs (zfs), на хороших контроллерах, с большим кэшем и дисками в режиме JBOD, вообще не теряет в производительности на паттернах БД, вплоть до заполнения массива на 80% и более.

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

Вот тебе пример для системного пула:

> ::spa
ADDR                 STATE NAME
ffffc10004418000    ACTIVE rpool
>
> ffffc10004418000::zfs_blkstats -v
Dittoed blocks on same vdev: 68392

Blocks  LSIZE   PSIZE   ASIZE     avg    comp   %Total  Type
     2    32K      4K   12.0K   6.00K    8.00     0.00  object directory
     2     1K      1K   3.00K   1.50K    1.00     0.00  object array
     1    16K     16K   48.0K   48.0K    1.00     0.00  packed nvlist
   601  3.14M   1.50M   4.51M   7.69K    2.08     0.03  SPA space map
   533  2.08M   1.42M   4.27M   8.20K    1.46     0.03    L0 SPA space map
    68  1.06M   84.0K    252K   3.70K   12.95     0.00    L1 SPA space map
     1     4K      4K      4K      4K    1.00     0.00  ZIL intent log
 15.3K   246M   46.8M   93.7M   6.08K    5.25     0.75  DMU dnode
 14.9K   239M   45.4M   90.8M   6.08K    5.25     0.73    L0 DMU dnode
   211  3.29M   1.06M   2.13M   10.3K    3.08     0.01    L1 DMU dnode
    52   832K    142K    284K   5.46K    5.85     0.00    L2 DMU dnode
    52   832K   52.0K    104K      2K   16.00     0.00    L3 DMU dnode
    52   832K   52.0K    104K      2K   16.00     0.00    L4 DMU dnode
    52   832K   52.0K    104K      2K   16.00     0.00    L5 DMU dnode
    52   832K   52.0K    104K      2K   16.00     0.00    L6 DMU dnode
    52   104K   26.0K   52.0K      1K    4.00     0.00  DMU objset
     7     4K   3.50K   10.5K   1.50K    1.14     0.00  DSL directory child map
    16     8K      8K   24.0K   1.50K    1.00     0.00  DSL dataset snap map
    24   198K   27.0K   81.0K   3.37K    7.33     0.00  DSL props
  351K  13.8G   8.90G   8.91G   26.0K    1.55    73.85  ZFS plain file
  344K  13.7G   8.89G   8.89G   26.5K    1.54    73.69    L0 ZFS plain file
 7.29K   117M   10.1M   20.3M   2.78K   11.47     0.16    L1 ZFS plain file
   129  2.01M    157K    313K   2.42K   13.18     0.00    L2 ZFS plain file
     3  48.0K   3.00K   6.00K      2K   16.00     0.00    L3 ZFS plain file
     1    16K      1K      2K      2K   16.00     0.00    L4 ZFS plain file
 43.0K   116M   29.6M   59.2M   1.37K    3.90     0.47  ZFS directory
 41.5K  92.0M   28.1M   56.2M   1.35K    3.27     0.45    L0 ZFS directory
 1.47K  23.5M   1.48M   2.96M   2.01K   15.91     0.02    L1 ZFS directory
    12  11.5K   6.00K   12.0K      1K    1.91     0.00  ZFS master node
    12    32K   6.50K   13.0K   1.08K    4.92     0.00  ZFS delete queue
 3.98K  3.00G   3.00G   3.00G    771K    1.00    24.86  zvol object
 3.93K  3.00G   3.00G   3.00G    781K    1.00    24.86    L0 zvol object
    40   640K   76.0K    152K   3.79K    8.42     0.00    L1 zvol object
    10   160K   13.5K   27.0K   2.69K   11.85     0.00    L2 zvol object
     3  2.50K   1.50K   3.00K      1K    1.66     0.00  zvol prop
     5   528K   85.5K    257K   51.2K    6.17     0.00  SPA history
     4   512K   84.5K    254K   63.3K    6.05     0.00    L0 SPA history
     1    16K      1K   3.00K   3.00K   16.00     0.00    L1 SPA history
     1    512     512   1.50K   1.50K    1.00     0.00  Pool properties
     1  1.50K     512   1.50K   1.50K    3.00     0.00  DSL dataset next clones
    84  72.0K   42.0K   84.0K      1K    1.71     0.00  ZFS user/group used
    12  6.00K   6.00K   12.0K      1K    1.00     0.00  SA master node
    12  18.0K   6.00K   12.0K      1K    3.00     0.00  SA attr registration
    24   384K   42.0K   84.0K   3.50K    9.14     0.00  SA attr layouts
    17  8.50K   8.50K   25.5K   1.50K    1.00     0.00  DSL deadlist map
    31  16.5K   15.5K   46.5K   1.50K    1.06     0.00  DSL dir clones
  414K  17.1G   11.9G   12.0G   29.8K    1.43    100.0  Total
>
anonymous
()
Ответ на: комментарий от anonymous

Собственно данные это вот эти две строки:

  344K  13.7G   8.89G   8.89G   26.5K    1.54    73.69    L0 ZFS plain file
 3.93K  3.00G   3.00G   3.00G    781K    1.00    24.86    L0 zvol object

Все остальное - метаданные разного рода. Соответственно данные занимают 98,55% используемого пространства, метаданные - 1,45%.

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

CoW негативно влияет на скорость работы с БД

Ну если у тебя любой запрос к заде банных требует фулл скана - то может быть (и то не факт, потому как приличного размера L2ARC может существенно все ускорить). А если нет - то все далеко не так очевидно, как кажется на первый взгляд. Если же у тебя много обновлений, то за счет CoW запись в датафайлы из случайной превратится в последовательную, в то время без CoW придется писать случайно.

anonymous
()

Мои SSD за 2 года пока что подтверждают только нормальное использование для дома.
В продакшене не встречал.

Myp3ik ★★
()

такой вопрос (по теме)..


у нас на ЛОР — кто-нибудь ведёт публичный список воинов-ZFS ?

если да — то это было бы очень полезно! потому что последнее время это уже переростает в какую-то болезнь..

например пару лет назад у меня сломалася раздел с файловой системой EXT4 , а до этого этот раздел опять ломался (на этом же жёстком диске). и вобщем это случалось примерно раза три.

проблема разумеется была именно в жёстком диске (веротянее всего в «игривом» контроллере :)), а не в файловой системе.

...но вот если бы на этом жёстком диске была бы не EXT4 а BTRFS — то бьюсь-об-заклад что воины-ZFS — меня съели бы с потрахами, сказав что виновата во всём именно BTRFS!! :-)

блин, ребята.. ну нельзя же так!

нужно обязательно завести учёт ZFS-воинов на этом форуме.. да!

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

ты сначала матчасть подтяни, а потом умничать пытайся.

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

По моим наблюдениям здесь куча ext4-хейтеров

мне кажется — врядли.. как можно ненавидеть ext4 ? это же просто обычная файловая система.. %) :)

это как сказать, например: «я ненавижу ...» ...эээээээ... «красного цвета носки!»

ты можешь не надевать на себя ни когда красные носки, но как ты можешь их ненавидеть? :-)

темболее если обаятельная леди захочет вступить с тобой в половую связь — то ты вряд ли отталкнёшь её, увидив что она пользуется красными носками :) ["нет! курва! на тебе крассные носки! убирайся к чёртовой бабушке! и не приведи линус, если я ещё и узнаю что у тебя на нетбуке — корень в ext4!" ]

Тут фанаты всех ФС обсирают хейтеров этих ФС. Особо я бы zfs-фанов не выделял.

раньше я не придавал этому значения.. но потом вдруг заметил что ZFS-воины перешли в своё интернет-наступление! :-)

..и вот опять в этой теме :)

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

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

Многие вещи нам непонятны не потому, что наши понятия слабы; но потому, что сии вещи не входят в круг наших понятий. (с) Козьма Прутков

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

яж регистрант :) — у меня есть такая возможность.. вот и использую её :-D

Лучше б не было. Глядишь, с первого раза головой бы думал.

а ещё я не ввожу капчу^W^W^W в нее ем :D

Исправил, можешь не благодарить :)

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

нормальное использование

нормальное (==перпендикулярное) чему?

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

Если же у тебя много обновлений, то за счет CoW запись в датафайлы из случайной превратится в последовательную

Ну не обязательно же.

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

COW, фрагментация и производительность: http://blog.delphix.com/uday/2013/02/19/78/

Основываясь на собственном опыте могу предположить, с большой долей вероятности, что cow-fs (zfs), на хороших контроллерах, с большим кэшем и дисками в режиме JBOD, вообще не теряет в производительности на паттернах БД, вплоть до заполнения массива на 80% и более

Ну и фразочка:
1. «Основываясь на собственном опыте»  — один год, типовое использование, малая нагрузка.

2. «с большой долей вероятности» — отмазка от ответственности

3. «на хороших контроллерах с большим кэшем и ...» --- отмазка. Т.е. в определенных условиях и др условиях и см. п2.

4. «вплоть до заполнения массива на 80% и более» — 80% и более — смотри вышеуказанный линк.

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

один год, типовое использование, малая нагрузка.

А как должно быть? 100 лет синтетических тестов, не имеющих ничего общего с реальной работой?

«с большой долей вероятности» — отмазка от ответственности

Это фигура речи, обозначающая, что так как у меня, на вполне конкретных железках, нет никаких проблем с производительностью, то скорее всего (предположительно) у вас тоже не будет проблем. Так понятно?

«на хороших контроллерах с большим кэшем и ...» --- отмазка

Согласен, здесь я должен указать конкретные модели. Контроллер должен быть вот такой http://www.lsi.com/products/raid-controllers/pages/megaraid-sas-9271-8i.aspx#... или лучше.

80% и более — смотри вышеуказанный линк.

Зачем мне смотреть линк, если я имею возможность проверить сам?

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

Зачем мне смотреть линк, если я имею возможность проверить сам?

Зачем верить твоим пустым словам, если есть линк на тесты?

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

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

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

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

Трудно что либо доказывать, если даже ссылки на официальную документацию оракла здесь ни во что не ставят. Это же «маркетинговый буллшит» и ссылаться на него может только оракло-бот, так ведь?

хочешь чтобы все это приняли за истину

Не хочу, мне всё равно. Люди интересуются, я отвечаю, в рамках своих скромных познаний. Продвигать zfs мне не нужно, я ей не торгую.

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

ссылки на официальную документацию оракла здесь ни во что не ставят.

Ставят, ставят, не надо за всех говорить.

Там написано что надо избегать (любой ценой, если дорога скорость) заполнения пула более 85%. И тест в указанном линке это замечательно иллюстрирует. при 10% скорость 6000, при 85% — 500

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

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

Не передёргивай. Я ту оракловскую простыню назвал костылями, а не ложью.

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

вообще не теряет в производительности на паттернах БД, вплоть до заполнения массива на 80% и более.

1. вообще не теряет в производительности

2. на 80% и более.

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

вообще не теряет в производительности

Вероятно на моих задачах фрагментация не так сильна, как у того перца, который рисовал графики. Повторяю, на моих серверах скорость до заполнения примерно в 80% заметно не падает, далее падение видно даже без тестов.

на 80% и более.

Не придирайся, очевидно это описка. При заполнении до 80%.

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

Не передёргивай. Я ту оракловскую простыню назвал костылями, а не ложью.

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

Да, и там не «оракловская простыня», а маленькая страничка с инструкцией )

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