Pode ter acabado de enroscar o vira-lata tentando seguir as instruções em outro thread para encolher meu RAID
Eu usei as instruções @Paul ( link ) em sua resposta a Reduza o RAID removendo um disco? mas acho que posso ter cometido um erro terrível. Aqui está o resumo ...
Estou atualizando as unidades de 4 TB no meu DS1813 +, uma a uma, com as unidades Seagate Ironwolf 10TB. Eu tinha uma unidade para atualizar, mas percebi que, em vez de passar pelo dia + processo de reconstrução da matriz após atualizar a unidade e depois passar pelo processo de Paul, em vez disso, eu simplesmente removia a unidade de 4 TB da matriz durante o processo de encolhimento. d ser capaz de falhar; infelizmente, esse não foi o caso e temo que agora seja tarde demais para meus 22 TB de dados. Aqui está minha sessão PuTTY:
ash-4.3# pvdisplay -C
PV VG Fmt Attr PSize PFree
/dev/md2 vg1 lvm2 a-- 25.44t 50.62g
ash-4.3# cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
md2 : active raid5 sdf3[13] sdh3[7] sdb3[9] sdg3[6] sde3[12] sdd3[11] sdc3[10] sda3[8]
27316073792 blocks super 1.2 level 5, 64k chunk, algorithm 2 [8/8] [UUUUUUUU]
md1 : active raid1 sdf2[5] sda2[1] sdb2[7] sdc2[2] sdd2[3] sde2[4] sdg2[6] sdh2[0]
2097088 blocks [8/8] [UUUUUUUU]
md0 : active raid1 sdf1[5] sda1[1] sdb1[7] sdc1[2] sdd1[3] sde1[4] sdg1[6] sdh1[0]
2490176 blocks [8/8] [UUUUUUUU]
unused devices: <none>
ash-4.3# exit
exit
Rob@Apophos-DS:~$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/md0 2.3G 940M 1.3G 43% /
none 2.0G 4.0K 2.0G 1% /dev
/tmp 2.0G 656K 2.0G 1% /tmp
/run 2.0G 9.8M 2.0G 1% /run
/dev/shm 2.0G 4.0K 2.0G 1% /dev/shm
none 4.0K 0 4.0K 0% /sys/fs/cgroup
cgmfs 100K 0 100K 0% /run/cgmanager/fs
/dev/vg1/volume_3 493G 749M 492G 1% /volume3
/dev/vg1/volume_1 3.4T 2.3T 1.1T 69% /volume1
/dev/vg1/volume_2 22T 19T 2.4T 89% /volume2
Rob@Apophos-DS:~$ pvdisplay -C
WARNING: Running as a non-root user. Functionality may be unavailable.
/var/lock/lvm/P_global:aux: open failed: Permission denied
Unable to obtain global lock.
Rob@Apophos-DS:~$ sudo su
Password:
ash-4.3# pvdisplay -C
PV VG Fmt Attr PSize PFree
/dev/md2 vg1 lvm2 a-- 25.44t 50.62g
ash-4.3# mdadm --grow -n5 /dev/md2
mdadm: max_devs [384] of [/dev/md2]
mdadm: this change will reduce the size of the array.
use --grow --array-size first to truncate array.
e.g. mdadm --grow /dev/md2 --array-size 15609185024
ash-4.3# mdadm --grow /dev/md2 --array-size 15609185024
ash-4.3# pvdisplay -C
PV VG Fmt Attr PSize PFree
/dev/md2 vg1 lvm2 a-- 25.44t 50.62g
ash-4.3# mdadm --grow -n6 /dev/md2
mdadm: max_devs [384] of [/dev/md2]
mdadm: Need to backup 2240K of critical section..
mdadm: /dev/md2: Cannot grow - need backup-file
ash-4.3# mdadm --grow -n5 /dev/md2
mdadm: max_devs [384] of [/dev/md2]
mdadm: Need to backup 1792K of critical section..
mdadm: /dev/md2: Cannot grow - need backup-file
ash-4.3# mdadm --grow -n5 /dev/md2 --backup-file /root/mdadm.md0.backup
mdadm: max_devs [384] of [/dev/md2]
mdadm: Need to backup 1792K of critical section..
ash-4.3# cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
md2 : active raid5 sdf3[13] sdh3[7] sdb3[9] sdg3[6] sde3[12] sdd3[11] sdc3[10] sda3[8]
15609185024 blocks super 1.2 level 5, 64k chunk, algorithm 2 [5/5] [UUUUU]
[>....................] reshape = 0.0% (216708/3902296256) finish=3000.8min speed=21670K/sec
md1 : active raid1 sdf2[5] sda2[1] sdb2[7] sdc2[2] sdd2[3] sde2[4] sdg2[6] sdh2[0]
2097088 blocks [8/8] [UUUUUUUU]
md0 : active raid1 sdf1[5] sda1[1] sdb1[7] sdc1[2] sdd1[3] sde1[4] sdg1[6] sdh1[0]
2490176 blocks [8/8] [UUUUUUUU]
unused devices: <none>
ash-4.3# cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
md2 : active raid5 sdf3[13] sdh3[7] sdb3[9] sdg3[6] sde3[12] sdd3[11] sdc3[10] sda3[8]
15609185024 blocks super 1.2 level 5, 64k chunk, algorithm 2 [5/5] [UUUUU]
[>....................] reshape = 0.0% (693820/3902296256) finish=3230.3min speed=20129K/sec
md1 : active raid1 sdf2[5] sda2[1] sdb2[7] sdc2[2] sdd2[3] sde2[4] sdg2[6] sdh2[0]
2097088 blocks [8/8] [UUUUUUUU]
md0 : active raid1 sdf1[5] sda1[1] sdb1[7] sdc1[2] sdd1[3] sde1[4] sdg1[6] sdh1[0]
2490176 blocks [8/8] [UUUUUUUU]
unused devices: <none>
ash-4.3# cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
md2 : active raid5 sdf3[13] sdh3[7] sdb3[9] sdg3[6] sde3[12] sdd3[11] sdc3[10] sda3[8]
15609185024 blocks super 1.2 level 5, 64k chunk, algorithm 2 [5/5] [UUUUU]
[>....................] reshape = 0.0% (1130368/3902296256) finish=6500.6min speed=10001K/sec
md1 : active raid1 sdf2[5] sda2[1] sdb2[7] sdc2[2] sdd2[3] sde2[4] sdg2[6] sdh2[0]
2097088 blocks [8/8] [UUUUUUUU]
md0 : active raid1 sdf1[5] sda1[1] sdb1[7] sdc1[2] sdd1[3] sde1[4] sdg1[6] sdh1[0]
2490176 blocks [8/8] [UUUUUUUU]
unused devices: <none>
ash-4.3# cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
md2 : active raid5 sdf3[13] sdh3[7] sdb3[9] sdg3[6] sde3[12] sdd3[11] sdc3[10] sda3[8]
15609185024 blocks super 1.2 level 5, 64k chunk, algorithm 2 [5/5] [UUUUU]
[>....................] reshape = 0.0% (1442368/3902296256) finish=6667.7min speed=9750K/sec
md1 : active raid1 sdf2[5] sda2[1] sdb2[7] sdc2[2] sdd2[3] sde2[4] sdg2[6] sdh2[0]
2097088 blocks [8/8] [UUUUUUUU]
md0 : active raid1 sdf1[5] sda1[1] sdb1[7] sdc1[2] sdd1[3] sde1[4] sdg1[6] sdh1[0]
2490176 blocks [8/8] [UUUUUUUU]
unused devices: <none>
ash-4.3# cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
md2 : active raid5 sdf3[13] sdh3[7] sdb3[9] sdg3[6] sde3[12] sdd3[11] sdc3[10] sda3[8]
15609185024 blocks super 1.2 level 5, 64k chunk, algorithm 2 [5/5] [UUUUU]
[>....................] reshape = 0.4% (18826624/3902296256) finish=6706.8min speed=9650K/sec
md1 : active raid1 sdf2[5] sda2[1] sdb2[7] sdc2[2] sdd2[3] sde2[4] sdg2[6] sdh2[0]
2097088 blocks [8/8] [UUUUUUUU]
md0 : active raid1 sdf1[5] sda1[1] sdb1[7] sdc1[2] sdd1[3] sde1[4] sdg1[6] sdh1[0]
2490176 blocks [8/8] [UUUUUUUU]
unused devices: <none>
ash-4.3#
Broadcast message from root@Apophos-DS
(unknown) at 22:16 ...
The system is going down for reboot NOW!
login as: Rob
[email protected]'s password:
Could not chdir to home directory /var/services/homes/Rob: No such file or directory
Rob@Apophos-DS:/$ sudo su
Password:
ash-4.3# cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
md1 : active raid1 sdh2[7] sdg2[6] sdf2[5] sde2[4] sdd2[3] sdc2[2] sdb2[1] sda2[0]
2097088 blocks [8/8] [UUUUUUUU]
[=====>...............] resync = 26.8% (563584/2097088) finish=2.4min speed=10314K/sec
md2 : active raid5 sdh3[7] sdb3[9] sdf3[13] sdg3[6] sde3[12] sdd3[11] sdc3[10] sda3[8]
15609185024 blocks super 1.2 level 5, 64k chunk, algorithm 2 [5/5] [UUUUU]
[>....................] reshape = 0.5% (19578240/3902296256) finish=10384.2min speed=6231K/sec
md0 : active raid1 sda1[1] sdb1[7] sdc1[2] sdd1[3] sde1[4] sdf1[5] sdg1[6] sdh1[0]
2490176 blocks [8/8] [UUUUUUUU]
unused devices: <none>
Agora, com a história por trás e a leitura do meu PuTTY, espero que alguém me diga como me desapertar. Acredito que o meu problema - depois de ter iniciado o processo sem previsão suficiente, consideração e compreensão total do processo em si - é duplo: eu não falhei o último 4TB restante de antemão assim o software estava baseando cálculos fora do menor tamanho de unidade de 4TB (provavelmente não levando em consideração os 70 TB de espaço entre as outras 7 unidades), e possivelmente meus comandos mdadm --grow de diferentes -n #.
ash-4.3# mdadm --grow -n5 /dev/md2
mdadm: max_devs [384] of [/dev/md2]
mdadm: this change will reduce the size of the array.
use --grow --array-size first to truncate array.
e.g. mdadm --grow /dev/md2 --array-size 15609185024
ash-4.3# mdadm --grow /dev/md2 --array-size 15609185024
ash-4.3# pvdisplay -C
PV VG Fmt Attr PSize PFree
/dev/md2 vg1 lvm2 a-- 25.44t 50.62g
ash-4.3# mdadm --grow -n6 /dev/md2
mdadm: max_devs [384] of [/dev/md2]
mdadm: Need to backup 2240K of critical section..
mdadm: /dev/md2: Cannot grow - need backup-file
ash-4.3# mdadm --grow -n5 /dev/md2
mdadm: max_devs [384] of [/dev/md2]
mdadm: Need to backup 1792K of critical section..
mdadm: /dev/md2: Cannot grow - need backup-file
ash-4.3# mdadm --grow -n5 /dev/md2 --backup-file /root/mdadm.md0.backup
mdadm: max_devs [384] of [/dev/md2]
mdadm: Need to backup 1792K of critical section..
Aqui está a saída atual de cat / proc / mdstat - notei que / dev / md2 mostra apenas 5 Us em comparação com os 8Us dos outros mds e isso me assusta, já que são todos volumes do mesmo grupo de RAID. 8 discos:
ash-4.3# cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
md1 : active raid1 sdh2[7] sdg2[6] sdf2[5] sde2[4] sdd2[3] sdc2[2] sdb2[1] sda2[0]
2097088 blocks [8/8] [UUUUUUUU]
md2 : active raid5 sdh3[7] sdb3[9] sdf3[13] sdg3[6] sde3[12] sdd3[11] sdc3[10] sda3[8]
15609185024 blocks super 1.2 level 5, 64k chunk, algorithm 2 [5/5] [UUUUU]
[>....................] reshape = 1.2% (48599680/3902296256) finish=6495.2min speed=9888K/sec
md0 : active raid1 sda1[1] sdb1[7] sdc1[2] sdd1[3] sde1[4] sdf1[5] sdg1[6] sdh1[0]
2490176 blocks [8/8] [UUUUUUUU]
unused devices: <none>
No mínimo, eu preciso salvar / dev / vg1 / volume_1. Espero não tocar naquele volume que será possível, mas neste momento não sei, já que todos os 3 volumes estão listados como "Crashed" no DSM. Eu estou esperando (mas não esperançoso) que uma vez que a Verificação de Consistência termine, tudo ficará bem.
Qualquer um que saiba mdadm estou precisando desesperadamente de sua ajuda! Paul, se você estiver lá, preciso da sua ajuda! Eu sei que eu estraguei tudo e há uma boa chance de eu perder tudo, mas se houver qualquer coisa que você possa sugerir que tenha alguma chance de salvar meu bacon, por favor me ajude!
Atualização (12/5/17): Nenhuma mudança, exceto a reformulação, continua progredindo - até 17,77% agora. O DSM ainda mostra todos os volumes como "Crashed (Checking parity consistency 17.77%)" enquanto o grupo de discos diz "Verificando os discos rígidos em segundo plano (Verificando a consistência da paridade em 17,77%)". Aqui está uma imagem do grupo de discos:
Eu acredito que a etapa crítica que eu perdi foi executar mdadm /dev/md2 --fail /dev/sdf3 --remove /dev/sdf3 ou remover manualmente a unidade - isso teria falhado a unidade 4TB restante e a removeria da matriz, deixando-me com uma matriz RAID 5 degradada de 7 x 10TB. Minha pergunta agora é - devo esperar até depois que a matriz é reformulada para remover a unidade de 4 TB? Ou devo ir em frente e falhar / remover agora? Meu senso comum diz que remover uma unidade durante uma reconstrução / remodelação resultará mal, já que isso é o que sempre aprendi, mas não sei se isso é necessariamente verdade nessa situação em que o mdadm está tentando empinar 7 unidades no valor de espaço em 5 unidades baseadas apenas no tamanho da unidade restante de 4 TB.
Além disso, caso seja útil, aqui está a saída de mdadm -D /dev/md2 :
/dev/md2:
Version : 1.2
Creation Time : Wed Mar 5 22:45:07 2014
Raid Level : raid5
Array Size : 15609185024 (14886.08 GiB 15983.81 GB)
Used Dev Size : 3902296256 (3721.52 GiB 3995.95 GB)
Raid Devices : 5
Total Devices : 8
Persistence : Superblock is persistent
Update Time : Tue Dec 5 17:46:27 2017
State : clean, recovering
Active Devices : 8
Working Devices : 8
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 64K
Reshape Status : 18% complete
Delta Devices : -3, (5->2)
Name : DS:2 (local to host DS)
UUID : UUID
Events : 153828
Number Major Minor RaidDevice State
7 8 115 0 active sync /dev/sdh3
8 8 3 1 active sync /dev/sda3
10 8 35 2 active sync /dev/sdc3
11 8 51 3 active sync /dev/sdd3
12 8 67 4 active sync /dev/sde3
6 8 99 5 active sync /dev/sdg3
9 8 19 7 active sync /dev/sdb3
13 8 83 6 active sync /dev/sdf3
O que me preocupa é que o tamanho da matriz está listado como 16 TB quando o tamanho total dos dados na matriz era superior a 20 TB. Não tenho certeza do que devo fazer neste momento. Qualquer pensamento ou experiência seria muito apreciado!
0 respostas
Tags partitioning raid mdadm synology