У меня есть 6 дисков (каждый 1,5 ТБ, все той же модели и версии прошивки), которые являются частью массива RAID5. RAID5 образует группу томов LVM и логическую группу. Последний содержит только один раздел ext3. Недавно я бегал:
e2fsck -f /dev/vg03/lv01 && resize2fs -M /dev/vg03/lv01
который завершился без ошибок.
Теперь, когда я пытаюсь mount /dev/vg03/lv01 Я получил:
EXT3-fs error (device dm-0): ext3_check_descriptors: Block bitmap for group 30533 not in group (block 1000532368)!
EXT3-fs: group descriptors corrupted!
Как мне выйти из этого затруднительного положения? Это вся информация, которую я могу вам сейчас дать:
fdisk -l /dev/sd[cdefgh] показывает (правильно), что они "Linux raid autodetect"
но теперь fdisk показывает:
fdisk -l /dev/md0
Диск / dev / md0: 7501,5 ГБ, 7501495664640 байт
...
Идентификатор диска: 0x00000000
Диск / dev / md0 не содержит действительной таблицы разделов
(вместо раздела типа LVM)
fdisk -l /dev/vg03/lv01
Диск / dev / vg03 / lv01: 7501,5 ГБ, 7501491732480 байт
...
Идентификатор диска: 0x00000000
Диск / dev / vg03 / lv01 не содержит допустимой таблицы разделов
(вместо раздела типа ext3)
Я пробовал:
e2fsck -fy /dev/vg03/lv01
e2fsck 1.41.12 (17 мая 2010 г.)
e2fsck: дескрипторы групп выглядят плохо ... попытки резервного копирования блоков ...
Битовая карта блока для группы 30533 не входит в группу. (блок 1000532368)
Переехать? даРастровое изображение индексного дескриптора для группы 30533 не входит в группу. (блок 1000532369)
Переехать? даЭтап 1: проверка инодов, блоков и размеров
Перемещение битовой карты блока группы 30533 в 1000524246 ...
Ошибка выделения 1 непрерывного блока (ов) в группе блоков 30533 для битовой карты inode: не удалось выделить блок в файловой системе ext2
e2fsck: прервано
Дополнительная информация, которую я могу вам дать:
cat /proc/mdstat
Личности: [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md0: active (только для автоматического чтения) raid5 sdg1 [0] sdh1 [5] sdf1 [4] sde1 [3] sdc1 [2] sdd1 [1]
7325679360 блоки уровня 5, блок 128 КБ, алгоритм 2 [6/6] [UUUUUU]
растровое изображение: 1/175 страницы [4 КБ], блок 4096 КБнеиспользуемые устройства:
Наконец, все тесты smartctl (short и extendend) не показали ошибок ни на одном из дисков.
Должен ли я попытаться resize2fs расти /dev/vg03/lv01 и повторить e2fsck ? Нужно ли мне cfdisk /dev/md0 и /dev/vg03/lv01 вернуться к своим настоящим типам?
Заранее спасибо за всю и любую помощь.
2011-09-20 ОБНОВЛЕНИЕ
Я выполнил следующие команды и смог перемонтировать раздел, но, просмотрев размер (df) до и после, кажется, что пропал 1 ТБ данных. При проверке MD5SUMS (из старой резервной копии) некоторых файлов с «такими же» файлами из перемонтированного раздела были обнаружены некоторые ошибки.
Для перемонтирования раздела были выданы следующие команды:
dumpe2fs / dev / vg03 / lv01
Block count: 1000491435<br />
Block size: 4096<br />
tune2fs -O ^ has_journal / dev / vg03 / lv01
resize2fs -p / dev / vg03 / lv01
dumpe2fs / dev / vg03 / lv01
Block count: 1831418880<br />
Block size: 4096<br />
монтировать -o ro, noatime / dev / vg03 / lv01 / mnt / raid
OK... but files have been damaged / gone missing.
Как вы вообще создали LVM? Вы подготовили физический том, используя /dev/md0 или ты сделал fdisk сначала и используйте один из разделов в качестве физического тома.
Если вы использовали все устройство в качестве PV, то fdisk не будет работать над этим, поскольку информация LVM будет размещена там, где fdisk ожидает найти таблицу разделов.
Что вы можете захотеть проверить, так это сделать vgdisplay -v /dev/vg03 чтобы увидеть, какие физические тома присутствуют в группе томов.
У вас raid 5 из 6 sd * блочных устройств без разделов. Теперь у вас есть lvm на рейде md0. Итак, вы создаете физический том из md0, группы томов с именем vg03 и одного логического тома с именем lv01. lv01 состоит из файловой системы ext3, которую вы хотите увеличить / уменьшить.
Выполняя это действие: e2fsck -f / dev / vg03 / lv01 && resize2fs -M / dev / vg03 / lv01, вы пытаетесь сжать файловую систему, которая была в точности ext3 (с журналом).
Насколько я знаю, resize2fs может изменять размер файловых систем ext2, но не файловых систем ext3, поэтому сначала вы должны удалить журнал.
Теперь, когда вы сделаете это с помощью tunefs, вы можете вернуться к работе файловой системы, которая позже была сломана resize2fs и fsck.
По этому поводу я могу посоветовать вам использовать только определенное программное обеспечение для восстановления, например ext3 undelete или что-то еще ...