вытянуть данные с lvm thin

запускать здесь lvconvert –repair стремно, может доламать.

Сдампи на другой носитель и там делай с ним что угодно.

xа я чет не могу понять как заставить lvs показать начальный и конечный блоки.

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

Сдампил. На другом мучаю.

Если они там есть

Глобально вроде ниче не рушилось

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

С таким подходом, чтоб использовать рядовой виндовс, надо знать внутреннюю структуру ntfs? Ну да ладно, сейчас не об этом

А речь не про то что что-то рушилось. Речь про то что понятия «начальный и конечный блоки» могут быть неприменимы к твоему виртуальному тому. Я от lvm всегда держался подальше (не люблю всякую муть) и не знаю как он устроен, но слово thin в названии очень намекает на то что никаких начальных-конечных блоков там нет, а есть более хитрая структура, и скорее всего плохо документированная.

Винду вообще не надо использовать, и да, в том числе и потому, что на внутреннюю структуру ntfs нет полноценной официальной документации.

в lvm последний блок может быть перед первым

злой ты и рефлексируешь понапрасну

Не живи, ведь на внутреннюю структуру окружающего тебя мира нет полноценной официальной документации.

в lvm последний блок может быть перед первым

Это я уже понял. Thin_dump -r показвает device-id=1, singlemapping origin block=6515 data block=9885327

Origin block=6516 data block=1153611

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

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 ничего не описано, тк описывать там нечего. Вкратце:

Мне то зачем учить? Это я тебе писал что зря ты с ним связался, не изучив предварительно что это такое (если б изучил не писал бы про начальный-конечный блоки). Ну вот сейчас ты наконец разобрался и теперь всё хорошо.

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

thick это по идее как раз и должен быть раздел с начальным-конечным блоками, только чуть усложнённый, но я не интересовался никогда

Увы, LVM вообще не имеет понятия начальный и конечный блоки.

С таким подходом, какую тогда блочную систему юзать? Выбор невелик по сути

P.s. LVM я так понял ты не юзаеш, описан плохо. ZFS? - может он и хороший, но я преимуществ не нашел ни одного, так чтоб просто так… Скорость - жрет RAM, надежность - как и у LVM thick. Ручное восстановление - за гранью реального.

Итого. Что остается?

С таким подходом

Каким? Что именно нужно то? Thin всегда будет такой, на любой реализации.

Каким?

Как я понял, lvm thin плохо описан - не юзать. Thick - не вникал, знач тоже не юзать.

Следовательно вопрос. Что юзать? ZFS? Он описан хорошо? Как по мне, не лучше чем LVM. А последствия падения zfs разгребали?

Я немного другое писал. Если ты теперь знаешь как устроен thin и все его потенциальные проблемы, то можешь осознанно его выбирать (если тебя в нём всё устраивает).

Если тебе интересен список вариантов, то их очень много. Thin можно сделать почти где угодно: его поддерживает, кроме lvm, тот же zfs, а так же практически любая современная файловая система в виде sparse files. А ещё, если речь про виртуалки, то у них есть thin-форматы образов дисков (в данном случае форматом управляет не хостовая ОС а гипервизор).

Thick можно сделать, вообще любым менеджером томов (в том числе просто разделы на диске - всегда thick), можно в виде предраспределённых файлов (dd if=/dev/zero of=filename bs= count=).

Чего ты докопался до lvm thin?

Он достаточно хорошо документирован и максимально прост по сравнению с остальными альтернативами. Proxmox его использует по умолчанию, а они довольно привередливые. К примеру, mdadm они отказались использовать.

Выбирать закрытые варианты типа vmware fs (управляет гипервизор) это хорошо по твоему? А когда он падает то его не поднять ничем, а из инструментов одна консольная утилита в esxi и все…

Про zfs вообще молчу. Этот комбайн умирает еще быстрей.

lvm один из самых проверенных вариантов.

Чего ты докопался до lvm thin?

Ещё один. Как ты читаешь вообще? Моя основная претензия была к тому, что автор стал его использовать, предварительно не разобравшись даже что это такое.

Выбирать закрытые варианты типа vmware fs (управляет гипервизор)

Гипервизор может управлять и у qemu, если что, и это не fs а просто thin-формат файла виртуального диска.

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

А если эта дырка попадет на метаданные ФС, то ФС придет хана.

А если эта дырка попадет на метаданные ФС, то ФС придет хана.

Тут на все 100% согласен. Не учел немного. Но вцелом, я не склоняю к тому что не нужны бэкапы. Они обязательны! Но тоже вопросов с proxmox конкретно есть… Просто так том не монтируется, говорит «я хз какая там ФС» - ну тут может я не до конца разбирался и заморачивался…

А ещё, если речь про виртуалки, то у них есть thin-форматы образов дисков (в данном случае форматом управляет не хостовая ОС а гипервизор).

Как говорилось выше, proxmox привередлив и такого в нем не замечено.

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

Т.е ты как сисадмин даеш себе полный отчет о том, что знаеш, какие данные и в каких физических блоках на дисках хардварный рейд хранит служебные данные? (я не вникал, но по факту, все контроллеры по разному, тк хардварный не всегда поднимается на разных контроллерах)

Или RAID это тоже фигня и пользовать его не нужно?

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

А про то, что я задал вопрос о том можно ли так сделать, я получил простой ответ

в lvm последний блок может быть перед первым

Что заставило меня посмотреть на вещи по другому и копать в другую сторону.

ИМХО, в проксмокс удобнее использовать ZFS вместо LVM.

С ним есть вопросы в надежности, это раз. И пожирание ресурсов это два. А скрутить zfs и выделить 512мб-1Гб оперативки - работает в 1,5 раза проторможенней чем lvm.

А тратить ram на ФС… Ну… Это если гонять на проксе 1-2 виртуалки, не ресурсоемких, которым нужна скорость диска (опять же в небольших обьемах).

P.s из личной практики. Zfs хорошо себя показывает при выделении от 32Гб оперативки и снова таки, если не дай бог ничего не ломается. Но не дай боже вылетит диск и нет бэкапов - все. А ситуации бывают разные

С ним есть вопросы в надежности, это раз. И пожирание ресурсов это два. А скрутить zfs и выделить 512мб-1Гб оперативки - работает в 1,5 раза проторможенней чем lvm.

Что насчёт btrfs?

Не раньше чем RH признает её production ready.

Не раньше чем RH признает её production ready.

Они выпилили поддержку BTRFS из коробки.

В RHEL 8 выпилили.
Может в RHEL 10 впилят.
А пока у них в почёте LVM + XFS.

Сорян, я немного неправильно выразился. Не какую FS юзать, а с блоками чем работать? Кроме LVM собственно ничего и не остается… Может потому и вопросов столько к той же zfs, в силу того, что в proxmox, например, используеш фс внутри виртуалки на фс гипервизора. И лечить соответственно надо фс гипервизора а потом разбираться с последствиями внутри виртуалок, а с блочным управлением типа lvm вытягиваеш живые куски ну а дальше дело техники

Не раньше чем RH

RH - долларовая шлюха IBM. Нашли на кого равняться.

а с блоками чем работать? Кроме LVM собственно ничего и не остается…

В zfs есть zvol. Но он медленнее lvm. И доставать данные из zfs сложнее чем из lvm.