Назад | Перейти на главную страницу

Целостность и стресс-тестирование btrfs

Коллега по DevOps рекомендует начать перевод нашей производственной среды на использование btrfs. У нас в основном файловые системы ext4, хотя некоторые малоиспользуемые серверы используют ZFS (в Linux). Как один из лиц, принимающих решения, и как человек, ответственный за нашу общую среду, я сомневаюсь, основываясь на количестве комментариев и статей о btrfs, находящихся в разработке в Интернете. Чтобы противостоять этому аргументу, Oracle выпустила свой Enterprise Linux с поддержкой btrfs, SLES 12 (https://www.suse.com/releasenotes/x86_64/SUSE-SLES/12/) также указывает, что он будет использовать btrfs, и есть свидетельства того, что такие компании, как Facebook, также используют его в контролируемых производственных средах.

Существует ряд аргументов в пользу того, почему движение в этом направлении (принятие btrfs) будет хорошим делом, и я в целом согласен с ними, однако я хотел бы быть осмотрительным, проявить должную осмотрительность и получить больше практических знаний и часов, проведенных в «небольшой производственной» или промежуточной среде, прежде чем двигаться дальше в более широком масштабе. Существуют ли какие-либо инструменты, которые могут помочь мне построить дело - например, стресс-тестирование с последующей проверкой целостности данных или что-то в этом роде? Кроме того, что вы не видите таких утверждений, как: «В. Является ли btrfs стабильным? Краткий ответ: нет, это все еще считается экспериментальным». на btrfs wiki, что еще я могу сделать, чтобы сделать пушистую теплее?

Я уже дал подробный ответ здесь: Готово ли производство btrfs?

Вкратце: Btrfs - это то, что вам уже нужно на производственном файловом сервере.

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

Кроме того, даже с ядром 3.16 известно, что он создает взаимоблокировки, что наверняка вам не нужно на производственном сервере (http://marc.merlins.org/perso/btrfs/post_2014-10-05_Btrfs-Tips_-Catch-Btrfs-Deadlocks.html). Также некоторые RAID все еще являются экспериментальными, например RAID5 / 6. Вы можете использовать их, но пока не можете очищать данные и другие вещи.

Fedora хочет наконец сделать Btrfs файловой системой по умолчанию с v23, что должно произойти в конце 2015 года. Red Hat перешла с Ext4 на XFS по умолчанию.

Если вам действительно нужна файловая система, готовая к производству COW, сделайте себе одолжение и воспользуйтесь ZFS как ZFS в Linux или во FreeBSD.

И прочитайте блог Рассела Кокера о его опыте работы с Btrfs. http://etbe.coker.com.au/

Я бы придерживался основных файловых систем, таких как XFS (продвигаемый Red Hat), и полагался на ZFS для расширенных потребностей файловой системы.

В основном это связано с:

  • Mindshare: Знания о ZFS хранятся в сообществах Linux, FreeBSD и Solaris / OpenIndiana.
  • Зрелость: Кодовая база ZFS проверена и существует уже некоторое время. Передовой опыт эволюционировал и я не могу вспомнить, что видел ужасные истории о потере данных.
  • Портативность: Я определенно сменил платформы и полностью сохранил совместимость с ZFS.

За исключением конкретной интеграции с контейнерами Linux, я не знаю, что BtrFS предлагает многое по сравнению с ZFS. Cегодня. Если вы сомневаетесь в использовании BtrFS, прислушайтесь к своему внутреннему голосу. Не думаю, что я поставлю на это бизнес, но со временем все может измениться. Оцените свои конкретные потребности. Есть ли в BtrFS привлекательные функции, которыми может воспользоваться ваша среда?

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