> Я не знаю, с чем вы работаете и какие у вас сроки поднятия из бэкапа.

Я тоже не знаю - ибо не требовалось, как максимум откат снапшота за пару минут. Странно взять звездолет с гипердрайвом и машиной времени и не попрыгать по мультивселенным с альтернативными реальностями. Да, это нелинейный менеджмент системы. Можно хоть эн параллельных веток эволюции отращивать. Или - send этого в VM -> receive -> о, мой десктоп теперь в VM где я и болтаю с вами. С снапшотами почти нет отличия между VM и bare metal...

> Мне нужно убдет отойти на 10-15 минут и я потеряю максимум час работы.
> Не смертельно, но неприятно. Ну и я не пользуюсь всякими хитрыми фичами.
> Т.е. вероятность проблем - приемлемая для меня ).

Я вот именно бэкапы делаю реже и на физически отключаемый винч, так что он переживет полный rm -rf, runaway dd в блочный девайс, или что там еще. А снапшот - скажем перед крупным апгрейдом системы и ключевого софта. Если не понравится, верну за 2 минуты как было "1 в 1". При том могу старый state оставить для изучения, в отличие от бэкапов. Мультивселенная!

> Да все равно мы упираемся в сырую производительность носителей...

В энтерпрайзных SSD - уже и в кишки ядра бывает. Потому и рефакторы типа folios, io_uring, вот это все. И для ФС рефакторы и редизайны тоже так то логичны.

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

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

Оверхед возможен на блоках с эн референсами, e.g. снапшотах, рефлинках, ... и у btrfs и bcachefs есть особенности, они несколько разные из за разного дизайна. Их актуально знать при активном использовании снапшотов. Это как с VM - там тоже ряд концепций в CoW дисках стоит понимать, не отращивая очень большие дельты или их разлапистые иерархии.

> дело, что чем больше фич, тем медленнее - вон, fat12 так
> вообще шустрый был...

У него индексов нет, с большими иерархиями FAT тормоз! И алокация педальная, эктентов там IIRC нет. Так что современные ФС его могут легко сделать. Боолее того - билд кернела ворочает около 250К файлов. И это не напрягает. Даже на btrfs. На FAT - удачи! Вы и на NTFS то это взвоете, там в разы тормознее все. А при 100К файлов в 1 дире в ntfs наступает апокалиптец, чтения диры дождаться малореально вообще.

> Да, то, что он заморачивается - это хорошо, конечно.

У него неплохое мышление. Мне не нравится его хайп с растом, хотя-бы из соображений build deps, но оно в данный момент там опционально.

>>Скажем FUSE реализация - вообще труп по сути.
> Не тыкал, не знаю, мне не нужно,

Убер-глючное на данный момент. Я бы мог найти пару сценариев где это имеет смысл, но для меня это low priority экспериментальная хрень, я сильно на вот это - не дергался.

> Падажжи. Если SSD затирается - он уходит в RO, либо отваливается совсем,

Щаззз! Есть еще минимум 1 режим отказов! Падлюка в меру дурости начинает выгружать порушеные данные, IO error не репортит - и нате вам шум океанов марса (видимо после неуспешного декодирования FEC). У меня даже такая флеха есть, но ЭТО замечено и для энтерпрайзных SSD под bcache, файлухи разумеется очень плохо на такие подарки реагируют и при игноре этого - осыпаются к хренам и зачастую наповал. Btrfs'ник с энтерпрайзным SSD попал под внимание потому что удивлялся:
- А это не баг в ФС? Орет постоянно CSUM FAILED?!
- А что за конфиг?
- Блаблабла, энтерпрайзный SSD, bcache, ...
- Не, чувак, это не баг в ФС! Срочно замени свой SSD под кешом! Иначе у тебя подохнет все и совсем.

Я потом видел еще несколкько случаев ЭТОГО в более жесткой форме, юзеры ext4 и xfs такое обычно замечают слишком поздно, когда оно - уже совсем хренакс. Чексумы по всей площади способствуют отлову ЭТОГО до того как оно приобретет совсем злой масштаб.

> либо не отдает прочитанные данные, так как чексуммы не совпадают и
> ECC не может уже их поднять у диска.

Или, как оказалось - отдает, левак какой-то. Btrfs в этом случае радостно орет на левые чексумы, чем хайлайтит полезность таковых лишний раз. У меня со временем даже такая флеха вот была отловлена и теперь у меня есть "reproducer", хоть и не энтерпрайзный, но поведение то же самое.

> А перед этим начинает сыпать в смарте проблемами...

Смарт рулится фирмварью и потому - его полезность и реалистичность весьма варьируется.

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

Как показали господа "в интерьере" это обычно скорее так:
- А чойта за баг в btrfs - csum failed?!
- Упс, а чойта мой ext4 развалился и совсем не маунтится? Был на bcache...

Несколько вот таких succes story навели тех кто интересовался вопросом на понимание определенного паттерна.

> умрет - умрут вместе с этим SSD и все данные, что
> лежат в background hdd.

Ну вот когда ФС кешируется bcache и SSD делает вон то, разлет получается хорош.

> я успею выставить durability=0 носителю и он превратится в writethrough и
> я спокойно смогу дожить до магазина ;).

КМК лучше хотеть durability == 2 (RAID1) для как минмум метаданных, а лучше и данных, если они ценные. И кстати EPIC WIN на эту тему что у кента что у btrfs мог бы быть если бы это можно было по файлам/дирам/subvol конфигурить, при том я готов поспорить что аллокатор сам по себе мог бы это обеспечить, просто конфигурационного интерфейса для такого нет. А желательно еще и устаканившегося и одинакового для ФС которые так умеют (с точки зрения настройки из юзермода). Next-gen дизайнам на самом деле душно с чистым POSIX.

>>Даже вот отловить косяки - тоже способ сказать спасибо.
> Чем и занимался, так-то. Просто при моем сетапе косяков не возникло а
> те, что есть - складируются и потом либо буду багрепортить, либо
> сам поправлю (хочу сам, например, баг со временем поправить).

Весьма похвальный подход к делу :). Вот все бы так. Учитесь ташкиновы и freehck как на самом деле надо было :P.