Уменьшение физического объема LVM на вершине mdadm деградировало массив RAID, добавив запасную и восстановив его

У меня есть система Debian Wheezy с двумя Debian Wheezy емкостью 500 ГБ в RAID-1 (зеркало mdadm ), поверх которой расположены логические тома LVM с 5 разделами ( boot , root , usr , var и tmp ), общий размер 47,15 ГБ , 418.38 GiB в физическом объеме свободны. GRUB установлен на обоих дисках.

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

Я хочу заменить все эти 2 жестких диска на SSD емкостью 80 ГБ без необходимости переустанавливать систему с нуля. Тонкая точка здесь заключается в том, что мне нужно уменьшить физический объем LVM, чтобы соответствовать размеру SSD, но логические тома не смежны (в начале есть много свободного места), поэтому мне нужно как-то переместить логические тома в физическом , И в Debian нет команды lvmove .

Как мне это достичь?

Некоторые консольные выходы:

Версии:

 root@wheezy:~# uname -a && mdadm --version && lvm version Linux wheezy 3.2.0-4-amd64 #1 SMP Debian 3.2.63-2+deb7u1 x86_64 GNU/Linux mdadm - v3.2.5 - 18th May 2012 LVM version: 2.02.95(2) (2012-03-06) Library version: 1.02.74 (2012-03-06) Driver version: 4.22.0 

Сведения о массиве:

 root@wheezy:~# mdadm -D /dev/md0 /dev/md0: Version : 1.2 Creation Time : Thu Dec 4 12:20:22 2014 Raid Level : raid1 Array Size : 488148544 (465.53 GiB 499.86 GB) Used Dev Size : 488148544 (465.53 GiB 499.86 GB) Raid Devices : 2 Total Devices : 1 Persistence : Superblock is persistent Update Time : Thu Dec 4 13:08:59 2014 State : clean, degraded Active Devices : 1 Working Devices : 1 Failed Devices : 0 Spare Devices : 0 Name : wheezy:0 (local to host wheezy) UUID : 44ea4079:b3b837d3:b9bb2ca1:1b95272a Events : 26 Number Major Minor RaidDevice State 0 8 16 0 active sync /dev/sdb 1 0 0 1 removed 

Краткие сведения LVM:

 root@wheezy:~# pvs && vgs && lvs PV VG Fmt Attr PSize PFree /dev/md0 system lvm2 a-- 465.53g 418.38g VG #PV #LV #SN Attr VSize VFree system 1 5 0 wz--n- 465.53g 418.38g LV VG Attr LSize Pool Origin Data% Move Log Copy% Convert boot system -wi----- 152.00m root system -wi----- 2.00g tmp system -wi----- 10.00g usr system -wi----- 20.00g var system -wi----- 15.00g 

Сегментация PV:

 root@wheezy:~# pvs -v --segments /dev/md0 Using physical volume(s) on command line PV VG Fmt Attr PSize PFree Start SSize LV Start Type PE Ranges /dev/md0 system lvm2 a-- 465.53g 418.38g 0 89600 0 free /dev/md0 system lvm2 a-- 465.53g 418.38g 89600 38 boot 0 linear /dev/md0:89600-89637 /dev/md0 system lvm2 a-- 465.53g 418.38g 89638 512 root 0 linear /dev/md0:89638-90149 /dev/md0 system lvm2 a-- 465.53g 418.38g 90150 5120 usr 0 linear /dev/md0:90150-95269 /dev/md0 system lvm2 a-- 465.53g 418.38g 95270 3840 var 0 linear /dev/md0:95270-99109 /dev/md0 system lvm2 a-- 465.53g 418.38g 99110 1280 0 free /dev/md0 system lvm2 a-- 465.53g 418.38g 100390 2560 tmp 0 linear /dev/md0:100390-102949 /dev/md0 system lvm2 a-- 465.53g 418.38g 102950 16226 0 free 

3 Solutions collect form web for “Уменьшение физического объема LVM на вершине mdadm деградировало массив RAID, добавив запасную и восстановив его”

Вам не нужно сжимать pv или перестраивать массив. Вам просто нужно создать новый массив из новых дисков и добавить его в качестве нового pv ( pvcreate + vgextend ), затем pvmove всех существующих lvs от старого pv, а затем удалить старый pv ( vgreduce ) и взять этот диск не работает.

Это не lvmove а pvmove .

 pvmove --alloc=anywhere /dev/md0:89600-102950 /dev/md0:0-12070 

Это должно перемещать любые экстенты в диапазоне 89600-102950 до диапазона 0-12070. Согласно опубликованным вами данным, это должно привести к тому, что ваши LV будут перемещены в начало вашего PV.

ВНИМАНИЕ: НАСТОЯЩЕЕ РУКОВОДСТВО ПРОСТО ОТ ОПТИМАЛЬНОГО. ПРОВЕРЬТЕ ПРИНЯТЫЙ ОТВЕТ

Хорошо, я понял, как делать то, что я пытался. Это будет своего рода учебник.

За это время я еще не понял, что манипуляции с LVs действительно возможны, когда файловые системы монтируются и загружаются в какой-то live Linux-дистрибутив (SystemRescueCD). Люди здесь объяснили мне, что в этом нет необходимости, если вы не манипулируете фактическими файловыми системами и просто выравниваете LV и уменьшаете PV.

Таким образом, с помощью этого руководства вы обязательно достигнете того, чего хотите, но не эффективным образом, потому что он сталкивается с самой природой LVM – возможностью делать что-то живое .

  1. Из-за несмежного характера логических томов на моем физическом объеме я должен каким-то образом переместить их в начале физического тома. Команда pvmove , предложенная @frostschutz, может перемещать LV в пределах PV :

     root@wheezy:/home/a# pvmove --alloc=anywhere /dev/md0:89600-102950 /dev/md0:0-12070 /dev/md0: Moved: 100.0% root@wheezy:/home/a# pvs -v --segments /dev/md0 Using physical volume(s) on command line PV VG Fmt Attr PSize PFree Start SSize LV Start Type PE Ranges /dev/md0 system lvm2 a-- 465.53g 418.38g 0 38 boot 0 linear /dev/md0:0-37 /dev/md0 system lvm2 a-- 465.53g 418.38g 38 512 root 0 linear /dev/md0:38-549 /dev/md0 system lvm2 a-- 465.53g 418.38g 550 5120 usr 0 linear /dev/md0:550-5669 /dev/md0 system lvm2 a-- 465.53g 418.38g 5670 2560 tmp 0 linear /dev/md0:5670-8229 /dev/md0 system lvm2 a-- 465.53g 418.38g 8230 3840 var 0 linear /dev/md0:8230-12069 /dev/md0 system lvm2 a-- 465.53g 418.38g 12070 107106 0 free 
  2. Теперь PV готов к сжатию до размера SSD (80 ГБ). 80 гигабайт на самом деле составляют 80000000000 байт:

     root@wheezy:/home/a# pvresize --setphysicalvolumesize 80000000000B /dev/md0 Physical volume "/dev/md0" changed 1 physical volume(s) resized / 0 physical volume(s) not resized root@wheezy:/home/a# pvs PV VG Fmt Attr PSize PFree /dev/md0 system lvm2 a-- 74.50g 27.36g 
  3. После этого я могу изменить размер самого массива. На этом уровне нет файловых систем, поэтому я получаю только одну команду mdadm --grow , которая также может использоваться для сжатия массивов. Размер должен быть введен в kibibytes , поэтому он составляет 80000000000/1024 = 78125000:

     root@wheezy:/home/a# mdadm --grow --size=78125000 /dev/md0 mdadm: component size of /dev/md0 has been set to 78125000K root@wheezy:/home/a# mdadm -D /dev/md0 /dev/md0: Version : 1.2 Creation Time : Thu Dec 4 12:20:22 2014 Raid Level : raid1 Array Size : 78125000 (74.51 GiB 80.00 GB) Used Dev Size : 78125000 (74.51 GiB 80.00 GB) Raid Devices : 2 Total Devices : 1 Persistence : Superblock is persistent Update Time : Thu Dec 4 17:56:53 2014 State : clean, degraded Active Devices : 1 Working Devices : 1 Failed Devices : 0 Spare Devices : 0 Name : wheezy:0 (local to host wheezy) UUID : 44ea4079:b3b837d3:b9bb2ca1:1b95272a Events : 60 Number Major Minor RaidDevice State 0 8 16 0 active sync /dev/sdb 1 0 0 1 removed 
  4. Теперь пришло время добавить существующий SSD к массиву и позволить ему перестроить:

     root@wheezy:/home/a# mdadm --add /dev/md0 /dev/sdc mdadm: added /dev/sdc root@wheezy:/home/a# cat /proc/mdstat Personalities : [raid1] md0 : active raid1 sdc[2] sdb[0] 78125000 blocks super 1.2 [2/1] [U_] [>....................] recovery = 1.3% (1081920/78125000) finish=11.8min speed=108192K/sec unused devices: <none> 

После восстановления у меня есть здоровый массив. Его члены могут быть заменены, и установка GRUB может быть выполнена регулярно (после загрузки в производственную систему) с помощью grub-install /dev/sdc .

  • массивы mdadm, ссылающиеся на одни и те же устройства
  • Отключить автоматическое обнаружение RAID во время выполнения
  • Определите процесс, который все еще использует файл в ленивой немонтированной файловой системе
  • Пытался разрастить мой массив raid6 с новым диском, получил «Не удалось восстановить критический раздел»
  • mdadm не автомонтирует диски raid0 под / media / storage
  • Является ли RAID6 еще избыточным во время роста?
  • Linux-рейд собрал «сам» с неисправным приводом. Зачем?
  • Каково значение bitmap в mdstat
  • Файловая система mdadm raid отличается от файловой системы диска
  • Разница между UUID от blkid и mdadm?
  • Восстановление RAID5 с использованием «mdadm --create ... missing»
  • Linux и Unix - лучшая ОС в мире.