Як відновити масив mdadm в Synology NAS з приводом у стан "E"?


12

Synology має індивідуальну версію драйвера md та наборів інструментів mdadm, яка додає прапор "DriveError" до структури прапорів rdev-> у ядрі.

Чистий ефект - якщо вам не шкода отримати помилку масиву (перший диск) у поєднанні з помилкою на другому диску - масив переходить у стан, що не дозволяє вам ремонтувати / реконструювати масив, навіть незважаючи на те, що читання з накопичувача працюють штрафу.

На даний момент я не дуже переживаю це питання з точки зору цього масиву, оскільки я вже витягнув вміст і маю намір реконструювати, але більше від того, щоб бажати мати шлях до вирішення цього питання в майбутньому , оскільки я вже вдруге пережив це, і я знаю, що бачив інших, що задають подібні запитання на форумах.

Підтримка Synology була менш ніж корисною (і, як правило, не реагує на реалізацію), і не надаватиме жодної інформації НА ВСІХ щодо боротьби з набором рейдів у коробці.

Зміст / 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>

Статус від 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

Як бачите - / dev / sda5 було додано до масиву. (Якраз цей диск виявився невдалим) - але, хоча md сприймає привід як запасний, він не відновиться до нього. / dev / sde5 у цьому випадку - проблемний диск із станом (E) DiskError.

Я спробував зупинити пристрій md, запустивши повторно збирати, видалити / прочитати sda5 з пристрою / тощо. Без змін у поведінці.

Я зміг повністю відтворити масив за допомогою наступної команди:

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

який повернув масив до цього стану:

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]

Потім я знову додав / dev / sda5:

mdadm --manage /dev/md2 --add /dev/sda5

після чого він розпочав перебудову:

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

Зверніть увагу на положення "відсутнього" накопичувача, що відповідає точному положенню відсутнього гнізда.

Як тільки це закінчиться, я думаю, що я, мабуть, потягнуть за собою сумнівний привід і зможу його відновити знову.

Я шукаю будь-які пропозиції щодо того, чи є якийсь "менш страшний" спосіб зробити цей ремонт - чи хтось пережив цей досвід із масиву Synology і знає, як змусити його відновити інше, ніж вимкнути пристрій md в автономному режимі та відтворення масиву з нуля.


Я опиняюся в подібній ситуації. Ви успішно вирішили це?
дворак

Так, мені вдалося відновити масив наступними кроками. Я все-таки прослідкував за цим очищенням і переходом з R5 на R6 - тому що в цей момент я серйозно незадоволений поведінкою Synology "танк на весь масив", що хотів переконатись, що терпить більше одного диска "невдало ". У нашому випадку другий привід, який мав помилку "пролом", пройшов розширені смарт-тести навіть без жодної проблеми.
Натан Нойлінгер

Дякуємо за корисний посібник. Я не надто впевнено боюся з усім цим, я не фахівець з рейдів. Зараз я зіткнувся з тією ж проблемою, але в моєму випадку у мене є один масив RAID 1 диска (/ dev / md3), при цьому / dev / sde3 позначається страхом [E]. Я припускаю, що мені слід дотримуватися тих же кроків, що і ви, але оскільки це єдиний диск масиву, я не знаю, що це буде робити ;-). Так чи інакше не вдасться команда mdadm - stop / dev / md3 (пристрій або ресурс зайнятий). Напевно, я ще трохи
подовжу

Якщо ви не можете зупинити масив, це здається, що щось його використовує - тобто він встановлений, або проти цього пристрою працює якась інша задача.
Натан Нойлінгер

2
На щастя для мене Synology допомогла мені виправити проблему. Вони були добрі, щоб забезпечити мені команди, якими вони керували. Я розмістив інформацію у своєму блозі, якщо хтось інший натрапив
dSebastien

Відповіді:


3

Просто доповнення до рішення, яке я знайшов після того, як пережив те саме питання. Я дотримувався публікації в блозі dSebastien про те, як відновити масив:

Я виявив, що той метод відтворення масиву працював краще, ніж цей метод. Однак після відновлення масиву обсяг все ще не відображався у веб-інтерфейсі. Ніхто з моїх LUN не показував. В основному, показує новий масив без нічого налаштованого. Я зв’язався із службою підтримки Synology, і він видалився, щоб виправити проблему. На жаль, вони зняли, поки я не був у пульта. Мені все ж вдалося зафіксувати сеанс і переглянув те, що вони зробили. Поки намагалися відновити деякі мої дані, накопичувач знову вийшов з ладу, і я знову опинився в тій же ситуації. Я відтворив масив, як у блозі dSebastien, а потім переглянув сеанс синології, щоб виконати їх оновлення. Після запуску наведених нижче команд на веб-інтерфейсі з'явився мій масив та LUN, і я зміг працювати з ними. У мене практично нульовий досвід роботи в Linux, але це були команди, які я виконував у своїй ситуації. Сподіваюся, це може допомогти комусь іншому, але будь ласка, використовуйте це на свій страх і ризик. Найкраще звернутися в службу підтримки Synology і домогтися їх виправити, оскільки ця ситуація може відрізнятися від вашої

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 

1

Ще одне доповнення: я потрапив у дуже схожу проблему на своєму пристрої з одним диском / RAID рівня 0.

Підтримка Synology була дуже корисною та відновила мій пристрій. Ось що сталося, сподіваюся, що це допомагає іншим:

Мій диск прочитав помилки на одному конкретному блоці, повідомлення в системному журналі ( dmesg) були:

[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

Через кілька секунд я отримав жахливий Volume 1 has crashedлист від свого пристрою.

- Відмова: Не забудьте замінити ім’я пристрою на ваші та не просто копіювати та вставляти ці команди, оскільки це може погіршити ситуацію! -

Після зупинки smb я зміг знову встановити розділ лише для читання та запустити e2fsk за допомогою перевірки поганих блоків ( -c):

umount /dev/md2
e2fsck -C 0 -v -f -c /dev/md2

(можна також e2fsck -C 0 -p -v -f -c /dev/md2запустити як можна більше без нагляду, хоча це не вийшло в моєму випадку, оскільки помилки довелося виправити вручну. Тому мені довелося перезапустити e2fsck. Conclusio: -p не має особливого сенсу в випадок помилки диска)

Хоча e2fsck вдалося виправити помилки, а smartctl також не показав більше збільшення Raw_Read_Error_Rate, гучність все ще не зможе встановитись у режимі читання-запису пристроєм. DSM все ще показав "гучність збій"

Тому я відкрив квиток із підтримкою. Потрібно пройти досить багато часу, щоб все почати спочатку, але врешті-решт вони виправили це, відновивши масив RAID за допомогою:

synospace --stop-all-spaces
syno_poweroff_task -d 
mdadm -Sf /dev/md2
mdadm -AfR /dev/md2 /dev/sda3

Обов’язково перевіряйте назви своїх пристроїв ( /dev/mdXі /dev/sdaX), перш ніж робити що-небудь. cat /proc/mdstatпокаже відповідну інформацію.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.