> CoW и журналирование это вообще разные вещи. Вон в bcachefs есть и
> журналирование и CoW. А в BTRFS накосячили By Design. Поэтому она
> такая ненадежная, ну.Поразвелось экспертов млин. Там ващет есть некий минимальный журнал под внутренние нужды, просто он далеко не главный элемент пейзажа в случае CoW, которые эквивалент полного журналирования достигают несколько иначе - сделав "журналом" всю площадь ФС. Откуда и нужда в GC, дабы неактуальное подчищать. Иначе из-за недеструктивной записи в сторону место постепенно кончится. Сложный GC и отложенная по времени деаллокация - это обратная сторона таких паттернов дизайна. В большинстве случаев это не проблема, но на интенсивно нагруженной ФС, забитой под завязку это следует учитывать по линии рисков ENOSPC (если забыть про фрагментацию и проч).
> Нормальная ФС _знает_, что запись не прошла после
> резкого отключения питания. А BTRFS - _не знает_.
А ему оно на самом деле и не надо. В CoW запись недеструктивная. И это как-то так: пишется новое, если прокатило - на это перевешивается "указатель" (апдейтятся метаданные). Если не прокатило (крах), то что получается - аналог 100% rollback зафейленых потуг. Ибо той записи никогда не существовало, это неаллоцированое место а вид ФС "немного более старый". А старое состояние никто и не уничтожал. Когда-то потом, если вон там все прокатило, за ним может и пришел бы GC, если больше никому эти блоки не нужны были.
Btrfs забавен тем что делает "рекурсивный" вариант трюка - к метаданным это все тоже применяется, по своему красивый фокус, изначально разработка кого-то из IBM чтоли.
Технически это эквивалент полного журналирования. Только без тормозов от двукратной записи. И таки слеты питания оно вполне себе переживает в общем случае. В частных - выключение SSD, и вообще флешатины, без команды шатдауна ДО снятия питания является технически-некорректным деянием (FYI - логится в смарте) и там уже никто ничего не гарантирует, начиная с производителя накопителя. Так что если что - а вот там в смарте все ходы записаны!
