Почти SOS... Похерин ext3...

Конечно перестал, в LVM нет возможности добавления разделов с данными. Оно тупо создало на нём свою структуру метаданных и всё.

На сколько глубоко эта структура пишется на диск, что затрагивает из мфт и как попробовать восстановить?

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

Пробовал... Чекдиск плевался и говорил что ему нужен чекдиск.линакс_лвм ...

скопируй для начала образ диска с помощью dd_rescue куда-нить
а потом натрави на него photorec или ещё что-то

«Похери'н» - это такое лекарство?

> На сколько глубоко эта структура пишется на диск, что затрагивает из мфт

не более чем 127,5 Kb, http://www.howtoforge.com/recover_data_from_raid_lvm_partitions

> и как попробовать восстановить?

Как тут уже советовали, забэкапить винт через dd, тип раздела вернуть на 83, попробовать указать fsck.ext3 другой суперблок.

http://www.flux.org/pipermail/linux/2004-March/014939.html

Руки блин лечить! pvcreate перезаписывает первые четыре мегабайта раздела. Максимум что ты можешь - попытаться найти копии суперблока за пределами первых четырех мегабайт, и начать попытку восстановления на основе этих данных, но... У тебя 3/4 inodes скорее всего уже уничтожены.

Ищи специалиста и готовь деньги, сам ты все равно ничего уже не сделаешь.

>«Похери'н» - это такое лекарство?

+1, тоже подумал про лекарство :-)

1. Тролль Иришка не нужна

2. Если фрагментация не сильная, то photorec из комплекта testdisk, нужен будет фторой носитель.

Спасибо всем, даже тем кто насрал в коментах без них бы я не узнал что такое похери'н, попробую восстановить предложенными методами. Если будут ещё какие мысли пишите. Заранее благодарен!

Главное - действительно dd и, по возможности, работа с копией.

Ага. Вот и ссылку даже подкинули:

http://poxe.ru/uploads/posts/2008-04/1207950276_x_5af24a3891.jpg

Объясните почему так важна на ваш взгляд работа именно с копией, а не с самим диском, по идее если диск не рушится со скоростью лавины и на него самому ничего не писать, состояние данных меняться не должно, да и программы которые вы предлагаете это же читалки... Поясните... Или всётаки не совсем читалки?

Для того, чтобы, если предложенный метод не сработал, у тебя остался бы исходный материал. Да и спасённые данные куда-то сохранять надо

fsck, например, будет чинит ФС именно на предложенной партиции

> но... У тебя 3/4 inodes скорее всего уже уничтожены.

Не факт. Не забываем про группы блоков и про то, что таблица инодов лежит не одним куском. В начале каждой группы лежит по её кусочку. У меня, например, каждая группа весит по 128мб и только 11 занятых инодов находится в первой группе (из более чем миллиона (!) занятых инодов на всей ФС)

Какой программой можно просканировать диск на предмет поиска резервных суперблоков? То что даёт mkfs.ext3 -n про резервные суперблоки не подходит, fsck -b не находит ничего по указанным адресам суперблоков...