> отмены в какой момент?IIRC "пока не снесен subvol с файлом-образом старой ФС". Забавная абстракция, а? :). Посмотри в их readthedocs детали, прикольно придумано.
> И что будет если управляющие структуры лежат по одинаковым офсетам (уж суперблок-то точно)?
Не помню что там, вероятно несколько блоков физически удвигают. Логически, старая ФС вписана в btrfs как "файл образа" в subvol "ее снапшота". Это защищает старый фс, оформляя все аллокации (включая и метаданные) как аллокации btrfs. При откате видимо возврат нескольких блоков назад. Остальное... у оригинала ничего и не менялось! Конвертор сделал btrfs метаданные, которые референсятся на те же файлы, поскольку трогать их было нельзя из-за защиты снапшотом, cow при записи выноски делает. Это идет в btrfs free space, которое заодно и extX free space был. Поскольку Ext метаданные никто не апдейтил, откат ессно в оригинальное состояние, как и ожидаемо от снапшота.
> вопрос в наличии места где это можно сделать. Его понадобится - много.
Его надо...
1) Для служебных структур btrfs.
2) Для свободного места btrfs.
Это вполне умеренно, bulk data никто не кантует! Конечно метаданные btrfs будут дублировать метаданные оригинала, но блоки будут референснуто прям из оригинала, не надо их копировать. Это ж cow/write anywhere! Что куда хочет то и референсит. Поэтому может и вон то защитить, и отреференсить, и запись редиректнуть в безопасный регион. Помнишь я говорил что ты не понимаешь истинную мощь технологий cow и write-anywhere? Это пример того что оно может.
> ну может дело было в какой-то проге? А может в том что места банально не было.
Я думаю что дело в том что в NTFS нет backrefs... Кент вон уже тоже заметил что у его сарая нет стены^W backrefs и скорость операций...не та которую он хотел!
> Казалось бы, что? При переписывании файлов внутри журналирующей метаданные fs?
А таки разлет был хорош. Записи же деструктивные! Это не cow где сперва "планируемую" копию сделали, а потом перевесили указатели, после чего GC может подгребать деаллоцированый старый вариант и мало места для лажи. А в деструктивной записи малейшее отклонение от идеала и усе, факап.
> У скольких мильенов навернулось питание при ночном defrag?
Не знаю. Но нескольким из - я вынимал данные с немоунтабельной виндой напроч нтфсины. Пришлось и вон там ту же магию, внепланово. Я более-менее все выцепил но времени убилось в разы больше планируемого и в итоге закончилось полным data move -> repartition -> возврат данных. Убийство времени и позор менеджмента систем.
> либо места на бесконечное стадо коров - не хватило.
Бесконечное не надо - только на маневровый регион, остальное GC может подгребать наздоровье, оно уже ни для чего не используется. После перевеса указателей - старый регион подлежит деаллокации. Теоретически надо места на 1 двигаемый экстент. Практически конечно супернеоптимально в таком виде.
> то на ней просто должно быть достаточно свободного места для манипуляций с
> двумя fs сразу. Чудес не бывает.
Есть 1 чудо: указателей на регион может быть более 1. Блоки будут реюзануты, место сожрется на второй набор метаданных. И конечно блоки оригинала нельзя деаллоцировать пока есть снапшот, иначе как откатывать?! Это просто креативное использование фич CoW. Люблю такое, так системщиков и архитектов видно.
> и зачем она нам? Какое-то совсем ненужное действо.
В случае btrfs
1) возможен откат на оригинал! крутое и стебное использование механики снапшотов.
2) конверсия делается с минимумом интрузива - основной объем не кантуют.
> Нам нужно просто не потерять данные, а этот откат - ну ок, один из возможных механизмов.
Ага! При этом с данными - да и метаданными старой ФС - ничего не случается, поводов для жесткого дестроя минимум. Они креативно крафтят второй набор метаданных по сути :)
> Как видим, довольно непростой и дорогой в реализации, может попроще стоило выбрать?
Чего такого дорогого в генерации второго набора метаданных по уже имеющемуся? Самое плохое что с этого происходит - не особо оптимальный лэйаут структур. Но это более-менее лечится, в доках написано как.
> Напоминаю, возможность ресайза вниз у ext4 - встроенная фича.
И чего? Ну попробуй вписать EXT4 в какой-нибудь другой ФС не разнося ту ФС в хламину. Сорян чтобы это работало - надо CoW семантику умеющую write anywhere.
> А зачем он нужен? Нам нужно просто не потерять данные если что-то пойдет не так.
> Точки восстановления, не, не слышали?
По моему они наоборот намного красивее тех костылей сделали. Юзанули мощь cow по полной и по сути 2 набор метаданных создают. И если юзер захочет то может откатиться на старую фс. Прикольная манифестация настоящей мощи cow.
> понятно. Лучше видимо избегать таких чудес.
Да. И про это в доке написано, как и что сделать если снапшот снесен для оптимизации лэйаута. Но абстракция стебная. И да - кому-то идея зашла, и они внешний тул ntfs2btrfs сделали, то же самое делает как я понимаю.
> троллейбусизбуханкижпг нам не надо обратно раз уж мы полезли в это - очевидно
> что мы хотим оригинал заменять (и вовсе не хотим выяснять потом
> как добавить к нему изменившееся, даже если откатимся).
Откат на снапшот - подразумевает потерю изменений с момента снапшотирования. Это как раз ожидаемое поведение абстракции "снапшот".
> Нам надо просто не потерять данные если в процессе что-то сбойнет.
> Но, видимо, был выбран механизм по принципу "где светлее".
Когда в руках молоток, все вокруг кажется гвоздями. Зачем изобретать костыли если вся механика умеющая это и намного круче уже была?!
>> Окей, а там можно откатиться на FAT если NTFS тебе не понравился?
> нет, зачем он мне если мы от него пытаемся уйти?
Eval сделать - с возможностью передумать.
> Что-то мне подсказывает что ТАКОЙ мне бы точно не понравился.
А я таки проперся таким импользованием механики фс. Норм сбитие вертолета автомобилем. Ну и откат такой технологии должен быть достаточно прост и мало что может обломаться. Если не создавать себе проблем "точками отката" и проч, не придется их героически решать.
