История изменений

Вообщем, мож кому пригодится.

LVM thin легче в в оперировании чем толстые тома, по крайней мере мне так показалось в силу того, что для тонких томов больше программ для оперирования.

по поводу

Нафига пользоваться «технологиями», не понимая как они внутри устроены?

Учите матчасть, сударь. Для LVM-thin ничего не описано, тк описывать там нечего. Вкратце: Основной важный раздел - tmeta (по умолчанию или metadata). Это по сути текстовый документ со структурой соответствия логических блоков физическим. Сами же тома - это условно отмеченные области, которые снова же отображаются исходя из описанного в tmeta.

Как итог - надо хранить бэкап\дамп рабочего tmeta, все остальное - не критично. В каком смысле? Обьясню.

Есть LVthin. он описан в metadata как disk-id=X и понеслась Origin block=6516 data block=1153611 (100500 записей) размеры блоков в зависимости от установленных вами для пула исоответственно физические на диске.

Все. Главное это параметр superblock и startblock и block count для тома tdata (он описан самым первым). И если вы в дампе даже тупо удалите строку соответствия блоков, то «снаружи» это вылезет дыркой в ФС (неважно какая она). Любая ФС от такого лечится (вспомним bad blocks на HDD) и все работает дальше. Если даже оухнет запись superblock, как у меня, то thin_dump -r прекрассно переваривает. Ечли очень плохо, то подсовываем новый раздел meta, с восстановленым бэкапом и фиксим.

P.S. структура метаданных в thick LVM - тяжелая и уже на легке вручную не лечится.

Если че не так описал или обьяснил поправляйте, буду рад коментам. Мож кому как мануал пригодится

Вообщем, мож кому пригодится.

LVM thin легче в в оперировании чем толстые тома, по крайней мере мне так показалось в силу того, что для тонких томов больше программ для оперирования.

по поводу

Нафига пользоваться «технологиями», не понимая как они внутри устроены?

Учите матчасть, сударь. Для LVM-thin ничего не описано, тк описывать там нечего. Вкратце: Основной важный раздел - tmeta (по умолчанию или metadata). Это по сути текстовый документ со структурой соответствия логических блоков физическим. Сами же тома - это условно отмеченные области, которые снова же отображаются исходя из описанного в tmeta.

Как итог - надо хранить бэкап\дамп рабочего tmeta, все остальное - не критично. В каком смысле? Обьясню.

Есть LVthin. он описан в metadata как disk-id=X и понеслась Origin block=6516 data block=1153611 (100500 записей) размеры блоков в зависимости от установленных вами для пула исоответственно физические на диске.

Все. Главное это параметр superblock и startblock и block count для тома tdata (он описан самым первым). И если вы в дампе даже тупо удалите строку соответствия блоков, то «снаружи» это вылезет дыркой в ФС (неважно какая она). Любая ФС от такого лечится (вспомним bad blocks на HDD) и все работает дальше.

P.S. структура метаданных в thick LVM - тяжелая и уже на легке вручную не лечится.

Если че не так описал или обьяснил поправляйте, буду рад коментам. Мож кому как мануал пригодится

Вообщем, мож кому пригодится.

LVM thin легче в в оперировании чем толстые тома, по крайней мере мне так показалось в силу того, что для тонких томов больше программ для оперирования.

по поводу

Нафига пользоваться «технологиями», не понимая как они внутри устроены?

Учите матчасть, сударь. Для LVM-thin ничего не описано, тк описывать там нечего. Вкратце: Основной важный раздел - tmeta (по умолчанию или metadata). Это по сути текстовый документ со структурой соответствия логических блоков физическим. Сами же тома - это условно отмеченные области, которые снова же отображаются исходя из описанного в tmeta.

Как итог - надо хранить бэкап\дамп рабочего tmeta, все остальное - не критично. В каком смысле? Обьясню.

Есть LVthin. он описан в metadata как disk-id=X и понеслась Origin block=6516 data block=1153611 (100500 записей) размеры блоков в зависимости от установленных вами для пула исоответственно физические на диске.

Все. Главное это параметр superblock и startblock и block count для тома tdata (он описан самым первым). И если вы в дампе даже тупо удалите строку соответствия блоков, то «снаружи» это вылезет дыркой в ФС (неважно какая она). Любая ФС от такого лечится (вспомним bad blocks на HDD) и все работает дальше.

P.S. структура метаданных в thick LVM - тяжелая и уже на легке вручную не лечится.