> ну это openzfs, у них все так работает.

Дык под винду сторонние дрова по моим наблюдениям вообще по жизни стремные. Так что те не исключение.

> дааа, технологии 70х-то (в которые уходят корнями extN и xfs) - проверены
> временем, не то что эти вот.

Так я btrfs'ом в основном пользуюсь, это уж никак не дезигн 70х, мод b-tree под cow сравнительно новая штука. Ну да, оно со своими приколами и странными наборами свойств. Но если с умом пользоваться, крутые фичи жестко перевешивают. А редгад пусть идет в пень, додуматься сделать "XFS другой версии" без конвертора/апгрейда это вообще было полное дно. "Пересоздайте ФС". Ну я и переделал остатки, в btrfs, там такое себе народ не позволяет.

> в ntfs есть снапшоты, причем правильно сделанные. ага, shadow именно для этого.

Правильно сделаные - это как? С CoW и записью только изменений, без разрушения старых состояний? А почему у них чекпойнт системы и откат взад такие конские времена занимает? На btrfs эти операции условно моментальные, и даже совсем вручную там больше минуты делать нечего, при том 95% времени будет печать команд и какой там еще ребут чтобы система с того снапшота была. Тасовка данных - ее по сути там нет, такая операция типа "переназначения указателей" по смыслу (на уровне аллокации и деревьев, но идея остается).

> Причем обратить внимание - общий механизм и для файлов, и для
> баз данных, которые могут расстроиться если им устроить crash consistence на
> уровне одной fs.

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

> А мне вот снапшоты в которые попадают разом конфиги операционной системы и
> файлы юзеров совсем не нравятся.

А у меня они и не попадают. Я взял идею из убунт, они хорошо придумали: корень ФС нигде не видно - "management world", он содержит весь "ансамбль миров" (снапшоты, и активные и остальные). Приятно быть "гипервизором" на bare metal. Там все subvolumes. Снапшоты - тоже subvolumes. Стоит сказать что subvolume - нечто типа директории. Идея покруче: это точки входа в иерархию CoW. Каждый subvolume можно снапшотить независимо от других. Это отдельный корень cow'd b-tree. Свободное место девайса или пула они динамически делят между собой, это не блочные штуки а иерархические.

При монтировании в стиле убунт цепляют 2 subvolume'а. Один на / как система. Второй в /home как data. Поэтому снапшоты независимы. Откат системы не ведет к профаку data в хомяке. Однако они оба делят место на системном диске(ах), аллокации соответствуют фактически занимаемым их файлами местам. Снапшоты изначально реюзают блоки с оригиналом, по мере расхождения COW конечно поддержит иллюзию независимости.

Чтобы увидеть всё - надо замаунтить корень btrfs. Там будут и активные снапшоты, и остальные, которые есть (можно и иначе но то - удобно). При том те могут быть как writeable так и readonly. Можно подрихтовать контент снапшота если пара файлов не нравится, сняв флаг readonly на время и вернув взад, если страшно повредить. С неких пор btrfs стал уметь стирать subvolume как просто диры. Случайно стереть не выйдет т.к. "management world" по нормальному не прицеплен, кроме случая когда охота порулить.

Больше всего похоже на менеджмент виртуалок с снапшотами только гранулярнее, можно не все откатывать. Можно и более гранулярно но мне кажется что деление на две части, system и user data хорошая идея.

При том этот процесс мне понятен, прозрачен, юниксвеен, ключевая его часть представлена как мега-иерархия ФС, и почти все сводится к файловым операциям.

Откат снапшота самому - примерно так (допустим что уже был @system-snapshot-1 с системой и @home-snapshot-1 с хомяком).

mount <файлуха> /management (показываем себе настоящий верхний уровань куда-нибудь)

mv /management/@home /management/@home-snapshot-2
mv /management/@home-snapshot-1 /management/@home
Это откат хомяка, для активации ремаунт /home или ребут, реманут с открытыми файлами может ине прокатить. Если текущее состояние не надо, /management/@home-snapshot-2 стираем. Можно сразу сделать снапшот еще раз, на случай если боимся испортить. Или до mv заснапшотить /management/@home-snapshot-1 и переключаться на копию, оставив /management/@home-snapshot-1 неизменным "источником", можно даже readonly сделать.

Или откат системы:
mv /management/@ /management/@system-snapshot-2
mv /management/@system-snapshot-1 /management/@home  

Эти примеры подразумевают именование и стиль из убунт, они монтируют @ и @home с btrfs как / и /home и придумали префиксом @. Самому btrfs пофиг, для него это "директории на стероидах".

А маунтится при буте такое нечто примерно как
LABEL=system /home btrfs defaults,noatime,subvol=@home,...

При этом в /home будет прицеплено содержимое subvolume из верха иерархии который назван @home. Сама эта иерархия остается невидима пока не прицеплен корень ФС без указания subvolume. Почти все операции условно-моментальны и весь откат занимает столько сколько нужно на грубо говоря переименование нескольких "дир". Операции с снапшотами и subvolumes вообще можно и btrfs subvolume <whatever> делать, но мне показалось прикольнее вертеть это из миднайта и btrfs звать приходится только для создания нового снапшота, остальное файловыми операциями.

> Поэтому ни для чего кроме бэкапов я ими и не пользуюсь.

Я ими пользуюсь... нууу, вот например, KiCad новой версии. Новый, клевый, но проект доделать надо. Черт знает - прокатит или нет. Снапшот системы. Ставим. Факъ, глюки. Разбираться - не сейчас, нафиг. Возвращаем старую систему, ребут, и вот у меня уже старый добрый вариант, все работает как часы. И все приключение пару минут. Что мне, долго пару дир передвинуть и ребут?

> Как страшно жыть.

Ну, дык, покупай себе гамно-оперативку, тоже к ним присоединишься. Я по приколу гонял на таких конфигах btrfs, он на чексуммы матерился активно. Но в винде чаще всего матюков вообще нет, а даже если и есть, когда там уже вермишель - они там где-то в ж... мира, в системном логе, кто ж из хомяков его читает. Заметят когда система в бсод начнет летать или перестанет цеплять это совсем.