> В любом случае я сказал как сделать сравнимый фокус btrfs'ной Я бы не сказал, что сказал
> если при рестрайпе питание слетит
Не слетит, там много аккумов
> Это такие очень мощные и клевые CoW-папочки
Оверлайфс это заменяет, костыльно, но из слоистой фс тоже можно извлечь профит.
> А диагностика вида "толи усб
в 100500 раз, - аппаратура впорядке, значит косяк в ПО, и то что он вылез на пустом месте о чем-то да говорит.
> Что-то почему-то сдохло но виноват бтр,
Не что-то, а бтр, не почемуто, а в типовом кейсе.
> выяснять не будем. Оок!
А что выяснять? перекомпилировать модуль ядра в режиме полной отладки и 2 месяца разгребать логи, мне за это не платят.
> А более умный народ так то за рабочие проекты кошелек готов открыть серьезно
фейспалм, продолбать данные = более умные, ты серьезно?
> Ну вон пыхнет питальник и пожжет все диски сразу,
Учебник по физики почитай, там (в нашей вселенной) есть схемы, которые могут пропускать не более чем Х тока, нормальный бп никогда не сожжет нагрузку.
> И выбирая между долботней самому или более сложной жизнью у аллокатора и механики ФС
Чем больше внедорожник, тем дальше бежать за трактором, идеальный алгоритм, который на 100% гарантирует что ты не потеряешь данные , это не иметь данных. а уж в какую сторону грести, чтобы иметь и не потерять - каждый сам выбирает, я не заморачивался на дисках, после того как электрики однажды ночью сожгли комп, я заморачивался на "бесперебойку", и это работает, - 4 часа держит, и это только половина батареек.
> склонным к урыванию данных порно с разделами и рестрайпом райдов
порно?
> Занимает уйму времени
> стремная и неудобная операция
> с кучей дурных ограничений.
> Технологии эпохи MSDOS.
lvm то?
нет, нет, нет и нет
во всяком случае не стремнее бтр, а ограничений куда меньше, впрочем тоже не панацея, но какбы git для проектов, бд для мелочевки, оверлай позволяет опускать данные по слоям раскидывая по датацентрам, просто надо организовать правильно, и не нужны будут финты ушами и хитрыми папочками.