The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Хостинг-оператор Anchor протестировал Btrfs на готовность к ..."
Версия для распечатки Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Исходное сообщение [ Отслеживать ]
Заметили полезную информацию ? Пожалуйста добавьте в FAQ на WIKI.
. "Хостинг-оператор Anchor протестировал Btrfs на готовность к ..." +/
Сообщение от Fracta1L (ok), 27-Апр-13, 14:58 
Имею ничтожный с точки зрения продакшн-одминов опыт использования на домашнем десктопе как Btrfs, так и ZFS. Стандартные задачи: гента + медиапомойка.

Btrfs использовал более года на SSD под системные (/ + /home) нужды.
Плюсы:
1) Снапшоты
2) Сжатие (lzo весьма увеличивает скорость ФС и экономит место на таких каталогах как исходники ядра или дерево portage)
3) Надёжность (было в общей сложности около 15 жёстких ребутов, ФС не теряла файлы и не требовала проверки/починки)
4) Томами (subvolumes) оперировать так же легко и прозрачно, как обычными каталогами
Минусы:
1) То, что в Btrfs называется снапшотами - по сути клоны, а не снапшоты, т.к. снапшот - это просто состояние ФС, его можно лишь прочесть, а в Btrfs в снапшоты можно и писать, что несколько неочевидно и снижает безопасность и сохранность)
2) Невозможно штатными средствами узнать сколько занимают снапшоты. Вообще, с диагностикой и аудитом у Btrfs огромные проблемы
3) Заметная (хотя и небольшая) просадка скорости работы с течением времени, особенно на большом количестве мелких файлов

ZFS в общей сложности использовал месяца четыре, как на SSD для / + /home, так и на HDD для файлопомойки.
Плюсы:
1) Высокая скорость работы на SSD, и, главное, стабильность этой скорости
2) Средства аудита и мониторинга великолепны. Штатными средствами можно узнать любую мелочь о созданных ФС и пулах
3) На одном пуле можно создать множество отдельных ФС ZFS с отдельными опциями (сжатие, чексуммы, кэширование и т.д.)
4) Снапшоты (только на чтение, можно делать откаты), клоны (это то, что в Btrfs называется снапшотами), дедупликация (жрёт оперативку в невменяемых количествах), сжатие (несколько алгоритмов на выбор), чексуммы (тоже несколько алгоритмов) и ещё куча всего, чего я даже пока ещё не пробовал.
5) Надёжность. Не представляю что нужно сделать чтобы убить эту ФС
Минусов тоже хватает:
1) Жрёт оперативку под кэши за обе щёки, при этом аппетит не поддаётся контролю.
2) При забитом кэше на HDD эта ФС демонстрирует просто редкостную слоупочность. Связано это с самими алгоритмами размещения файлов на носителе - ZFS и фрагментация это единоутробные братья. Пример: есть каталог со скриншотами, который на Ext4 открывается (в KSnapshot, например, или в Dolphin) мгновенно, на ZFS с полным кэшем же он открывается несколько десятков секунд
3) Как мне кажется, вполне способна убить HDD раньше времени, т.к. бешено дёргает головки туда-сюда
4) В Linux приходится замещать встроенные в ZFS средства монтирования штатным средством Linux (mount), т.к. при выключении какие-то траблы с отмонтированием
5) Этой ФС нет и не будет в ядре, поэтому приходится возиться с initramfs

В данный момент использую ZFS на SSD под систему и на одном HDD под медиапомойку. Уже сожалею, что впилил её на HDD, но снова меремещать туда-сюда 700 Гб данных уже неохота.

Ответить | Правка | Наверх | Cообщить модератору

Оглавление
Хостинг-оператор Anchor протестировал Btrfs на готовность к ..., opennews, 26-Апр-13, 23:34  [смотреть все]
Форумы | Темы | Пред. тема | След. тема



Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру