> В LVM тоже самое делается, только безопасней (на мой взгляд).

Btrfs на поверку переживает крах и ребут даже при конверсии схемы RAID, на минуточку. И потом может возобновить конверсию, без напряга. Или даже жить неопределенное время с смесью схем, дизайну так то похрен: 1 из вариантов конверсии это запрос новой схемы для НОВЫХ записей, а старые блоки вообще не трогать. Ему так то пофиг, это логически-корректная ситуация для того дизайна. Ни к каким суровым проблемам сие не ведет.

> У тебя атомарная функция (скорее всего) на уровне FS progs, а LVM это отдельная
> сущность, вначале добавляешь диски, а потом только действия по раширяемости с ФС.

В случае btrfs это вообще совсем иначе случается и радикально подперто внутренней механикой ФС.

Есть block groups с той или иной схемой хранения. Просто регионы аллокации, 1...несоколько гиг на том или ином девайсе, для хранения данных или метаданных. Экстент лежит там или сям, у него вот такая схема хранения (RAID1 значит что те же блоки дублированы на другом девайсе/девайсаз). При конверсии схемы хранения экстент как я понимаю сперва создается с новой схемой, в другие блочные группы, после этого переназначаются указатели, а если все вышло, можно маркировать старый регион как свободный. Остальные операции ворочаются в таком же стиле. Де факто оно может быстро и довольно безопасно "расчистить регион интереса". А было это для конверсии схемы (перепрофилирования типа BG в иной), уменьшения ФС, изъятия девайса, или чего там еще - да не так уж важно, core логики примерно одинаковое. Ну вот такой вот забавный крутой дизайн. Пока вы там на конской хребитине бока пинали, другие тут уже эвон какие звездолеты с гипердрайвом вона как научились. И да, это атомарное - сперва копия, потом апдейт указателей на нее, потом деаллокация. Прелесть cow в том что аналог полного журнала халявен.

И как вы понимаете - там не так уж много поводов для облома операций в таком то стиле. При крахе неудачная операция сама аннулируется "как обычно" - пока указатели не переназначили в новую локацию, этого вообще не существует. И это не блочный уровень уже, а скорее file-aware и space-aware, по backref известно чье оно, и можно удвигать только то что реально аллоцировано, со знанием дела. Если мы хотим почистить 10 гиг хвоста, и там чьи-то 100 кило на дороге стоят, удвигаются только эти 100 кило. И после этого можно спокойно откусить 10 гиг. Этим интеграция с ФС и аллокатором и крута.

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

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

> VOLUME отдельно, RAID отдельно, FS отдельно. Никакого компота, каждый на своём уровне

И в результате менеджмент становится миндфаком. Операции становятся медленными и печальными. А RAID1 сам по себе понятия не имеет ни какой файл побился, ни какая копия верная и не сделает self heal из исправной копии вот так сразу, в фоне, сам.

В чем разница? Вон то в btrfs 1 командой делается. И даже на 1 девайсе похожее можно. И все это прозрачно, ненапряжно. А у вас спятишь пока даже половину от этого нарулишь в этом месиве циферблатиков, проводочков и стрелочек. А чтобы все и сразу - в вон том виде... эм...

И да, знаете, когда оно само заруливает случайный разовый бэд, легко расширяется, конвертится, проверяет корректность работы железа чексум и проч - это прсото другой уровень менеджмента систем. Кент это понимает в отличие от "такпривыкли". Мир не вернется к более быстрым лошадям когда уже можно звездолет, как угодно.