Comment récupérer un tableau MDADM sur Synology NAS avec lecteur dans l'état "E"?
Synology a une version personnalisée Le pilote MD et les outils d'outils MDADM ajoutant un drapeau "dériveur" à la structure RDev-> drapeaux dans le noyau.
Effet net - Si vous êtes assez malheureux pour obtenir une défaillance de la matrice (premier lecteur), combinée à une erreur sur un deuxième lecteur - le tableau entrave dans l'état de ne pas vous laisser réparer/reconstruire le tableau même si les lisions du lecteur fonctionnent. amende.
À ce stade, je ne suis pas vraiment inquiet à propos de cette question du point de vue de ce tableau, car j'ai déjà tiré du contenu et que j'ai l'intention de reconstruire, mais plus de vouloir avoir une voie de résolution pour cela à l'avenir. Étant donné que c'est la deuxième fois que j'en ai été peu élevé, et je sais que j'ai vu d'autres poser des questions similaires dans des forums.
La prise en charge de la synologie a été moins que utile (et surtout non réactive) et ne partagera aucune information AT tout sur le traitement des raidsets sur la boîte.
Contenu de/proc/mdstat:
ds1512-ent> cat /proc/mdstat
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
md2 : active raid5 sdb5[1] sda5[5](S) sde5[4](E) sdd5[3] sdc5[2]
11702126592 blocks super 1.2 level 5, 64k chunk, algorithm 2 [5/4] [_UUUE]
md1 : active raid1 sdb2[1] sdd2[3] sdc2[2] sde2[4] sda2[0]
2097088 blocks [5/5] [UUUUU]
md0 : active raid1 sdb1[1] sdd1[3] sdc1[2] sde1[4] sda1[0]
2490176 blocks [5/5] [UUUUU]
unused devices: <none>
Statut d'un MDADM --Detail/Dev/MD2:
/dev/md2:
Version : 1.2
Creation Time : Tue Aug 7 18:51:30 2012
Raid Level : raid5
Array Size : 11702126592 (11160.02 GiB 11982.98 GB)
Used Dev Size : 2925531648 (2790.00 GiB 2995.74 GB)
Raid Devices : 5
Total Devices : 5
Persistence : Superblock is persistent
Update Time : Fri Jan 17 20:48:12 2014
State : clean, degraded
Active Devices : 4
Working Devices : 5
Failed Devices : 0
Spare Devices : 1
Layout : left-symmetric
Chunk Size : 64K
Name : MyStorage:2
UUID : cbfdc4d8:3b78a6dd:49991e1a:2c2dc81f
Events : 427234
Number Major Minor RaidDevice State
0 0 0 0 removed
1 8 21 1 active sync /dev/sdb5
2 8 37 2 active sync /dev/sdc5
3 8 53 3 active sync /dev/sdd5
4 8 69 4 active sync /dev/sde5
5 8 5 - spare /dev/sda5
Comme vous pouvez le constater -/dev/sda5 a été ré-ajouté à la matrice. (C'était le lecteur qui a échoué de manière simple) - mais même si MD voit le lecteur comme épargnée de réserve, elle ne la reconstruirea pas./dev/sde5 Dans ce cas, le lecteur de problème avec l'état (E) DiskError.
J'ai essayé d'arrêter le périphérique MD, l'exécution de la force de l'exécution, de la suppression/de la lecture SDA5 de l'appareil/etc. Aucun changement de comportement.
J'ai pu recréer complètement la matrice avec la commande suivante:
mdadm --stop /dev/md2
mdadm --verbose \
--create /dev/md2 --chunk=64 --level=5 \
--raid-devices=5 missing /dev/sdb5 /dev/sdc5 /dev/sdd5 /dev/sde5
qui a ramené le tableau à cet état:
md2 : active raid5 sde5[4] sdd5[3] sdc5[2] sdb5[1]
11702126592 blocks super 1.2 level 5, 64k chunk, algorithm 2 [5/4] [_UUUU]
J'ai ensuite ré-ajouté/dev/sda5:
mdadm --manage /dev/md2 --add /dev/sda5
après quoi cela a commencé une reconstruction:
md2 : active raid5 sda5[5] sde5[4] sdd5[3] sdc5[2] sdb5[1]
11702126592 blocks super 1.2 level 5, 64k chunk, algorithm 2 [5/4] [_UUUU]
[>....................] recovery = 0.1% (4569508/2925531648) finish=908.3min speed=53595K/sec
Notez la position du lecteur "manquant" correspondant à la position exacte du logement manquant.
Une fois que cela finit, je pense que je vais probablement tirer le lecteur discutable et le faire reconstruire à nouveau.
Je cherche des suggestions quant à savoir s'il existe une manière "moins effrayante" de faire cette réparation - ou si quelqu'un a traversé cette expérience avec un tableau de synologie et sait comment le forcer à reconstruire autrement que de prendre le périphérique MD hors ligne et recréer le tableau à partir de zéro.
Juste un ajout à la solution que j'ai trouvée après avoir connu le même problème. J'ai suivi DSEbastien Blog sur la procédure de recréation de la matrice:
J'ai constaté que cette méthode de recréer la matrice fonctionnait mieux que cette méthode ci-dessus. Cependant, après avoir ré-créé la matrice, le volume n'était toujours pas affiché sur l'interface Web. Aucun de mes LUN n'étaient montrant. Essentiellement montrant un nouveau tableau sans rien configuré. J'ai contacté le support de synologie et ils ont été reconstitués pour résoudre le problème. Malheureusement, ils ont été reconstitués pendant que j'étais à l'écart de la console. J'ai réussi à capturer la session et j'ai examiné ce qu'ils ont fait. Tout en essayant de récupérer certaines de mes données, le lecteur s'est encore écrasé et j'étais de retour à la même situation. J'ai recréé le tableau comme dans le blog de Dsebastien, puis j'ai examiné la session de synologie pour effectuer leur mise à jour. Après avoir exécuté les commandes ci-dessous, mon tableau et ma LUN sont apparus sur l'interface Web et j'ai pu travailler avec eux. J'ai pratiquement zéro expérience de Linux, mais c'étaient les commandes que j'ai effectuées dans ma situation. J'espère que cela peut aider quelqu'un d'autre, mais s'il vous plaît utiliser cela à vos risques et périls. Il serait préférable de contacter le support de synologie et de les amener à résoudre ce problème pour vous, car cette situation pourrait être différente de la vôtre.
DiskStation> synocheckiscsitrg
synocheckiscsitrg: Pass
DiskStation> synocheckshare
synocheckshare: Pass SYNOICheckShare()
synocheckshare: Pass SYNOICheckShareExt()
synocheckshare: Pass SYNOICheckServiceLink()
synocheckshare: Pass SYNOICheckAutoDecrypt()
synocheckshare: Pass SYNOIServiceShareEnableDefaultDS()
DiskStation> spacetool --synoblock-enum
****** Syno-Block of /dev/sda ******
//I've removed the output. This should display info about each disk in your array
DiskStation> vgchange -ay
# logical volume(s) in volume group "vg1" now active
DiskStation> dd if=/dev/vg1/syno_vg_reserved_area of=/root/reserved_area.img
24576+0 records in
24576+0 records out
DiskStation> synospace --map_file -d
Success to dump space info into '/etc/space,/tmp/space'
DiskStation> synocheckshare
synocheckshare: Pass SYNOICheckShare()
synocheckshare: Pass SYNOICheckShareExt()
synocheckshare: Pass SYNOICheckServiceLink()
synocheckshare: Pass SYNOICheckAutoDecrypt()
synocheckshare: Pass SYNOIServiceShareEnableDefaultDS()
DiskStation> synocheckiscsitrg
synocheckiscsitrg: Not Pass, # conflict
DiskStation> synocheckiscsitrg
synocheckiscsitrg: Pass
Un autre ajout: j'ai frappé un problème très similaire avec mon périphérique à un seul disque/RAID 0.
La prise en charge de la synologie était très utile et restauré mon appareil. Voici ce qui s'est passé, j'espère que cela aide les autres:
Mon disque avait lu des erreurs sur un bloc de particulier, les messages du journal système (dmesg) étaient les suivants:
[4421039.097278] ata1.00: read unc at 105370360
[4421039.101579] lba 105370360 start 9437184 end 5860528064
[4421039.106917] sda3 auto_remap 0
[4421039.110097] ata1.00: exception Emask 0x0 SAct 0x2 SErr 0x0 action 0x6
[4421039.116744] ata1.00: edma_err_cause=00000084 pp_flags=00000003, dev error, EDMA self-disable
[4421039.125410] ata1.00: failed command: READ FPDMA QUEUED
[4421039.130767] ata1.00: cmd 60/00:08:b8:d2:47/02:00:06:00:00/40 tag 1 ncq 262144 in
[4421039.130772] res 41/40:00:f8:d2:47/00:00:06:00:00/40 Emask 0x409 (media error) <F>
[4421039.146855] ata1.00: status: { DRDY ERR }
[4421039.151064] ata1.00: error: { UNC }
[4421039.154758] ata1: hard resetting link
[4421039.667234] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl F300)
[4421039.887286] ata1.00: configured for UDMA/133
[4421039.891777] ata1: UNC RTF LBA Restored
[4421039.895745] ata1: EH complete
Quelques secondes plus tard, j'ai reçu la terrible Volume 1 has crashed mail de mon appareil.
- Disclaimer: Assurez-vous de remplacer le nom du périphérique par vous et ne pas simplement copier et coller ces commandes, car cela pourrait aggraver les choses! -
Après avoir arrêté SMB, j'ai pu ré-monter la partition en lecture seule et exécuter E2FSK avec chèque Badblocks (-c):
umount /dev/md2
e2fsck -C 0 -v -f -c /dev/md2
(on pourrait aussi utiliser e2fsck -C 0 -p -v -f -c /dev/md2 Pour fonctionner aussi sans surveillance que possible, bien que cela ne fonctionnait pas dans mon cas, car les erreurs devaient être fixées manuellement. Je devais donc redémarrer e2fsck. Conclusio: -P n'a pas beaucoup de sens en cas d'erreur de disque)
Bien que E2FSCK ait été capable de réparer les erreurs et SmartCTL n'ayant plus montré plus d'augmentation de Raw_Read_error_rate, le volume n'aurait toujours pas monté en mode lecture-écriture par l'appareil. DSM a toujours montré "volume écrasé"
J'ai donc ouvert un billet avec support. Il a fallu un certain temps pour que les choses vont d'abord, mais à la fin, ils l'ont fixée en reconstruisant le tableau RAID avec:
synospace --stop-all-spaces
syno_poweroff_task -d
mdadm -Sf /dev/md2
mdadm -AfR /dev/md2 /dev/sda3
Assurez-vous de vérifier les noms de votre appareil (/dev/mdX et /dev/sdaX) Avant de faire quoi que ce soit. cat /proc/mdstat montrera les informations pertinentes.