> В любом случае я сказал как сделать сравнимый фокус btrfs'ной

Я бы не сказал, что сказал

> если при рестрайпе питание слетит

Не слетит, там много аккумов

> Это такие очень мощные и клевые CoW-папочки

Оверлайфс это заменяет, костыльно, но из слоистой фс тоже можно извлечь профит.

> А диагностика вида "толи усб

в 100500 раз, - аппаратура впорядке, значит косяк в ПО, и то что он вылез на пустом месте о чем-то да говорит.

> Что-то почему-то сдохло но виноват бтр,

Не что-то, а бтр, не почемуто, а в типовом кейсе.

> выяснять не будем. Оок!

А что выяснять? перекомпилировать модуль ядра в режиме полной отладки и 2 месяца разгребать логи, мне за это не платят.

> А более умный народ так то за рабочие проекты кошелек готов открыть серьезно

фейспалм, продолбать данные = более умные, ты серьезно?

> Ну вон пыхнет питальник и пожжет все диски сразу,

Учебник по физики почитай, там (в нашей вселенной) есть схемы, которые могут пропускать не более чем Х тока, нормальный бп никогда не сожжет нагрузку.

> И выбирая между долботней самому или более сложной жизнью у аллокатора и механики ФС

Чем больше внедорожник, тем дальше бежать за трактором, идеальный алгоритм, который на 100% гарантирует что ты не потеряешь данные , это не иметь данных. а уж в какую сторону грести, чтобы иметь и не потерять - каждый сам выбирает, я не заморачивался на дисках, после того как электрики однажды ночью сожгли комп, я заморачивался на "бесперебойку", и это работает, - 4 часа держит, и это только половина батареек.

> склонным к урыванию данных порно с разделами и рестрайпом райдов

порно?

> Занимает уйму времени
> стремная и неудобная операция
> с кучей дурных ограничений.
> Технологии эпохи MSDOS.

lvm то?

нет, нет, нет и нет

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