> с чего вдруг? md этот создается один раз и работает вечно, его
> трогать вообще больше не надо.Половина пойнта btrfs - в том что нет этой фиксации навечно как в более обычных RAID. И можно переиграть все под текущие нужды, на лету. Если они изменились - то и ФС можно подрихтовать. Плавно и без ухода в аут. А рулить им как XFS'ом/EXT4/... - работает, конечно, но...
> ну если тебе в принципе нравится синтаксис btrfs - то поприятнее, поскольку
> все в одном месте, а не отдельно fs, отдельно lvm, в
> двух разных ипостасях, снапшоты там, свободное место сям, кто на ком
> стоял поди разбери, и кого чинить если отвалится, тоже.
А еще фичи логично интегрированы. Снапшоты неплохо ложатся на механику ФС. А файлуха нормально относится даже к тому что половина стоража в одном формате райда, а половина в другом. И все это можно гибко переигрывать по ходу дела. Допустим решил некто RAID5 вместо зеркала сделать. Доткнул третий диск. Запустил конверсию. Файлуха продолжит работать пока рестрайпер жует блоки. И даже в случае облома - оно просто продолжит конверсию дальше. Механика нормально относится к тому что здесь и сейчас часть блоков в RAID1, а часть в RAID5. На самом деле оно нормально отнесется даже к тому что разные файлы или subvolume - с разными уровнями RAID. Когда заходит вопрос о метаданных оно может к ним ДРУГУЮ схему избыточности применить, опять же. И, ясен фиг, это требует именно плотного взаимодействия на стыке файловых операций и блочного уровня. У btrfs'а файлуха на самом деле принимает решение какие chunk-и выбрать под схему хранения нужную для вот этой вот записи вот этого вот добра - и пытается это изыскать на девайсах с свободным местом. Это позволяет расширить стораж просто подоткнув еще 1 девайс, совершенно не парясь. С точки зрения балансировки нагрузки - ребаланс потом может и иметь смысл сделать, но это наглухо опционально. Файлуха просто возьмет в оборот свободное место на девайсе(ах) и покуда на других девайсах было свободное место, оно без проблем скроит запрошенную схему хранения.
А вот как например расширить классический RAID, допустим, 5 после дотыкания в него 1 диска, без полного рестрайпа всей штуки, как абсолютно MANDATORY операции, к тому же исключающую нормальное использование пула на момент рестрайпа... мне почему-то кажется что индусня из редхата с их пихтонрастом вот эту вот часть системной магии ну вообще совсем никак не осилит. Потому что это уже не про маркетинговый булшит, а про awareness ФС и ее работы с низким уровнем относительно желаний более высокого уровня. Этот awareness в обычном RAID как раз аккуратно грохается уровнями абстракций и нагоном дешевой индусни с пихтонрастом и громким маркетингом все это НЕ ЛЕЧИТСЯ.
> в общем, не вижу особых проблем у такой конфигурации, кроме сомнений в
> надежности обоих ее компонент. Но в случае xfs + lvm сомнений не меньше.
Я бы очень не хотел пытаться отколупать XFS с какого-нибудь RAID56, под LVM, да еще с снапшотом и менеджментом на пихтонрасте делающем со всем этим фиг знает что. Хотя-бы потому что индусня с пихтонрастом потом даже сказать не сможет - что мне с этим пулом вообще делать...
