Вопрос по LVM

Зависит от способа объединения.

Да. Собрать lvm с учётом пропавшего винта, прогнать fsck, смириться с потерей тонны файлов, бывших на накрывшемся винте.
Предполагается, что lvm не striped.

Безнадёжно.

прогнать fsck, смириться с потерей тонны файлов

Вот только ни одна версия Ext* ФС не перенесёт потерю таблицы дескриптора групп — основы метаданных — расположенной в логическом начале тома.

Ответ теоретический: если данные не были дублированы на других носителях то накрывает медный таз.

>Вот только ни одна версия Ext* ФС не перенесёт потерю таблицы дескриптора групп — основы метаданных — расположенной в логическом начале тома.
Хватит 4.2. Копий этой таблицы — десятки на больших разделах.

> Вот только ни одна версия Ext* ФС не перенесёт потерю таблицы дескриптора групп — основы метаданных — расположенной в логическом начале тома.

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

Оно разве не с блоками данных работает? У тебя хороший план, но накроется значительно больше данных, чем просто файлы на накрывшемся винте.

Можно проверить: сделать LVM на трёх файлах, убрать один, посмотреть на эффект.

А можно просто погуглить:

google://LVM+allocation+policy

Хотя правильный вывод можно сделать и без всего этого.

Я про таблицу дескрипторов групп. Ты — про суперблок. Очевидно, что таблица дескрипторов групп не сводится к суперблоку, так что не пори чушь.

Сделал. Забил нулями второй файл, сделал fsck и примонтировал.

@madoka~>md5sum -c sum.txt|grep FAILED|wc -l
md5sum: WARNING: 62 computed checksums did NOT match
62
@madoka~>wc -l sum.txt
143 sum.txt
@madoka~>df -h /mnt/test
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/test-test
1.5G 1.5G 0 100% /mnt/test

Вывод: ФС выжила. Файлы достаточно разного размера, возможно, поэтому умерло больше трети файлов.

Попробуй из трёх файлов забить нулями первый.

Хм. Нужно будет угадывать номер суперблока (что не слишком сложно).

Суперблок здесь не главное.

В ext4 есть бекап и таблиц дескрипторов групп. Сюрприз?

Да дискусия развернулась огого , наскольколько я понял из всего прочитанного данные востановить не удастся(ну то что это не рэйд было ясно сразу ), вопрос тогда в следующем есть ли смысл использвать LVM вообще? К примеру диски объединить я могу и помощью mddfs ?

mhddfs

Любой lvm-раздел можно на лету увеличить (а если ФС умеет, то и уменьшить), причём место для увеличения может браться откуда угодно (т.е. можно не думать, между какими разделами какого диска есть свободное место).
Точно так же можно на лету создать новый раздел (в том числе и объединяя разрозненные куски места). Или удалить. Поэтому на LVM обычно делают разделы минимальных разумных размером, а позже при необходимости их увеличивают. Запас можно расходовать на снапшоты.

Станут недоступными те тома, которые целиком или частично лежали на ушедшем в небытие HDD.

>Я про таблицу дескрипторов групп. Ты — про суперблок. Очевидно, что таблица дескрипторов групп не сводится к суперблоку, так что не пори чушь.
Да, это разные вещи, но судя по твоей фразе:

таблицы дескриптора групп — основы метаданных — расположенной в логическом начале тома.

у тебя кашка в голове манная.

> Да дискусия развернулась огого , наскольколько я понял из всего прочитанного данные востановить не удастся(ну то что это не рэйд было ясно сразу ),
часть данных удастся востановить, если это конечно не страйп при котором от фс у тебя останется нарезанная тонкими полосочками капуста, которую восстановить будет проблематично.

Если тебе нужна избыточность, то в LVM можно делать mirror раздела, будет аналогично RAID 1, только на уровне соответственно раздела а не винта.

но судя по твоей фразе:

таблицы дескриптора групп — основы метаданных — расположенной в логическом начале тома.

у тебя кашка в голове манная.

Это у тебя каша.

> Это у тебя каша.
нет ты!

>частично лежали на ушедшем в небытие HDD.
Я уже показал, что это не так.

> Я уже показал, что это не так.

Да доказывайте себе на здоровье, но советую помнить - средствами LVM вы «разваленный» раздел не поднимите. Будет давать ошибку при первой же попытке чтения, так что придется поплясать с бубном (большим).

Вопрос — говно, пардон за мой французский.

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

А если у вас ФС на одном диске (без ЛВМ) и диск начнет сыпаться бэдблоками, возможно ли после этого восстановление информации?

>средствами LVM вы «разваленный» раздел не поднимите.
Э?
-P | --partial
When set, the tools will do their best to provide access to volume groups that are only partially available (one or more physical
volumes belonging to the volume group are missing from the system). Where part of a logical volume is missing, /dev/ioerror will
be substituted, and you could use dmsetup (8) to set this up to return I/O errors when accessed, or create it as a large block
device of nulls. Metadata may not be changed with this option. To insert a replacement physical volume of the same or large size
use pvcreate -u to set the uuid to match the original followed by vgcfgrestore (8).

А что при этом будет с ФС — в этом треде уже показано.

бубном (большим).

Если читать ман ≡ бить в бубен, то, может, стоит посмотреть в сторону windows 7? Хотя там бубен нужен заметно больших размеров.

да просто у них в путти неудобно маны читать.

Если читать ман ≡ бить в бубен

Может, вы сначала попробуете сами прочитать man? «When set, the tools will do their best to provide access to volume groups that are only partially available». Ключевое слово здесь - volume group, а не logical volume. И --partial вам ничем не поможет, пока вы не вернете на место старый диск (или его замену через pvcreate).

>Ключевое слово здесь - volume group, а не logical volume.
И?

(или его замену через pvcreate).

Его заменой может быть не физический диск. Дальше что?