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

Это некое базовое свойство дизайна ФС - заранее подумали о том что для разных вещей могут хотеть разные уровни RAID. Поэтому оно технически допускает произвольную смесь RAIDов с пообъектной гранулярностью выбора.

> (я с трудом себе представляю как можно с raid1+0 перейти на raid5+0 без подсказок),

Как я уже сказал - ложки нет. Вы мыслите RAID на уровне блочных устройств. А тут RAID на уровне аллокатора, пообъектно. Допустим у вас пул из 10 дисков. Для btrfs есть 10 дисков. На дисках есть эн свободного места, на каждом по разному, например. Это суммарная рабочая площадь пула. Пришел юзер, попросил "RAID1 для вон того файла". Файлуха пошла и при записи положила блоки файла на диски номер 3 и 5, допустим. На дисках 3 и 5 стало меньше свободного места. Блоки содержат 2 копии, как просили. А потом еще дописали. И это допустим пошло на диски 4 и 9. На дисках 4 и 9 тоже стало меньше свободного места. Эти блоки тоже содержат 2 копии. Смерть ни 1 из дисков пула не приводит к потере всех копий. Т.е. условия RAID1 - выполняются.

А теперь допустим мы хотим сделать из этого ну пусть RAID5. Как это может выглядеть? Прочли блоки файла которые были сохранены как RAID1, записали их как RAID5 (если для этого достаточно дисков и свободного места), деаллоцировали блоки RAID1 (вернув место занятое под них), отапдейтили метаданные (чтобы указывали на новые блоки с новой схемой размещения). Вроде все логично и не вижу почему это не может работать. По сути конверсия любой схемы в любую с точки зрения файлухи - нечто наподобие копирования файла.

При этом можно добавить новую схему которая будет сразу использоваться для новых данных без перетряски старых данных совсем, а потом можно неспешно по мере желания старые данные читать и записывать с новой схемой размещения. А так чтобы немедленно подрываться конвертить данные на 100500 дисках - не придется вообще.

> во-вторых это уже ведет к граблям с разбалансом btrfs, когда оно вдруг
> начинает думать что у него места нет.

Действительно, если вы допустим попросите RAID1, а свободное место есть только на 1 диске, извините, "места нет". Потому что нельзя выполнить запись по запрошенному критерию. С другой стороны, ребалансер может чего-то отыграть, равно как место может быть поюзано для иных схем хранения. В то время как на block-level RAID если диски разные, "лишнее" свободное место в хвосте диска как правило вообще втyпую пропадает.

Да, при этом понятие свободного места становится интересной штукой :-). А там еще CoW с GC, etc.

> сомневаюсь что btrfs сама это сможет учитывать, а поэтому все эти
> умные штуки очень сомнительны.

Если не давит жаба чуть ли не каждому диску по контроллеру ставить - может не удавит жаба и делать в духе гугли? Там вообще "если 1 сервер умер, никто ничего не замечает" ;).

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

> Это все круто, но сложно. Получится - замечательно, но пока оно далеко
> от готовности.

Фокус в том что если такие вещи не предусмотреть заранее, потом это заимплементить без тотального слома совместимости уже практически невозможно. А эти без проблем прикрутят те или иные схемы дублирования и четности RAID, при том существующим данным это жить никак не помешает. А потом при желании можно неспешно перемигрировать старые данные в новый вариант хранения.

> Диски разных размеров, это проблемы с производительностью в будущем. btrfs вам в
> лучшем случае их сможет использовать так, чтобы они данными заполнились равномерно,
> в худшем случае вы также потеряете то место, которое больше минимального диска.

Место на "большем" диске можно потратить, например, для хранения файлов для которых избыточность вообще не просили. А ребалансер может до некоторой степени пролечивать ситуации, когда перекос по каким-то причинам вышел аномально крутой. Не идеально? Ну да, некий tradeoff с некими свойствами. Но мне такой ход мыслей нравится.

> И в btrfs надо делать перестройку и в ZFS, просто btrfs умеет
> делать ее на месте. Это круто в домашних условиях, может быть
> еще полезно на ненагруженых серверах.

Это круто в том плане что все это можно делать без остановки работы ФС на фиг знает сколько и полного пересчета всего и вся. Плюс можно добавить 1-2 диска в пул и сделать ребаланс. Какие там уровни RAID у хранимых данных были и какие размеры дисков - не очень принципиально, ситуация с свободным местом всяко улучшится. В целом это позволит делать многодисковые конструкции гибче и переигрывать по ходу пьесы ряд решений без заваливания всего и вся в даун на черти-сколько.

> Заполнилось, добавляем еще места:

Теперь начинаю не совсем понимать я. Ну, ок, допустим я юзал RAID5. Теперь я хочу добавить еще 1 диск, чтобы суммарное место пула увеличилось. И как это будет выглядеть в терминах ZFS? И чтоб без разбора/дестроя многодисковых сущностей с полным пересчетом, разумеется. Btrfs отрастит +эн терабайтов на общей площади, изначально - "концентрировано" на этом диске, но после пинка ребалансера данные в фоне с всех дисков частично подвинутся на тот - в целом больше места станет глобально/независимо от типа RAIDа у разных объектов.

> Переделать в один raidz1 на 6 дисков - нельзя, да.

Ну а у btrfs можно в принципе перегонять объекты из одного типа RAID в другой по ходу пьесы. С технической точки зрения это read() с старой схемы, write() с новой схемой и снос старых блоков+апдейт метаданных. Ну так, чисто архитектурно. Что из этого по факту запилено - второй вопрос, по крайней мере та механика которая есть к таким вещам отнесется нормально и все это не проблема прикрутить, как и разные схемы избыточности/четности ... без порчи жизни админам на предмет разбора/пересоздания многодисковых пулов, масс-пересчета данных здесь и сейчас и прочего традиционного кластерфака.

> Расскажите это маленьким самолетам вроде Цесны.

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

> самом деле реактивные самолеты это нишевая штука.

По объему перевозок они давно все остальные обставили. А если смотреть на всякую мелочь, FAT давно всем врезал пинка: вон он на куче мелочи типа флешек и карт памяти :). Только вот почему-то нынче фат только на мелочи и остался, а использовать его на системном диске и хранилищах данных почему-то теперь никто не хочет.