Fehler beim Neuaufbau von Linux-Raid-1

2645

Ich habe eine Linux-Box, die als Heim-NAS mit 2 x 1 TB HDDs in Linux Raid-1 fungiert. Vor kurzem fiel eines von zwei Laufwerken aus, also kaufte ich ein neues Laufwerk (1 TB WD Blue) und legte es an. Der Wiederaufbau beginnt und endet bei 7,8%. Es wird ein Fehler angezeigt, dass / dev / sdd (das gute Laufwerk) einen fehlerhaften Block enthält und der Prozess nicht mehr fortgesetzt werden kann. Das neue Laufwerk wurde entfernt / hinzugefügt, der Prozess wird jedoch immer am selben Punkt angehalten Eine gute Nachricht ist, dass ich immer noch Zugriff auf meine Daten haben kann, die unter / storage (xfs fs) eingehängt sind. Außerdem gebe ich weitere Informationen zum Problem:

Die gute (Quell-) Platte:

sudo fdisk -l /dev/sdd   WARNING: GPT (GUID Partition Table) detected on '/dev/sdd'! The util fdisk doesn't support GPT. Use GNU Parted.   Disk /dev/sdd: 1000.2 GB, 1000204886016 bytes 255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disk identifier: 0x00000000  Device Boot Start End Blocks Id System /dev/sdd1 63 1953525167 976762552+ da Non-FS data 

Die neue (Ziel-) Festplatte:

sudo fdisk -l /dev/sdc  Disk /dev/sdc: 1000.2 GB, 1000204886016 bytes 81 heads, 63 sectors/track, 382818 cylinders, total 1953525168 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk identifier: 0x5c5d0188  Device Boot Start End Blocks Id System /dev/sdc1 2048 1953525167 976761560 da Non-FS data 

Das RAID-1-Array:

cat /proc/mdstat Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] md3 : active raid1 sdc1[3] sdd1[2] 976761382 blocks super 1.2 [2/1] [U_] [=>...................] recovery = 7.7% (75738048/976761382) finish=601104.0min speed=24K/sec 

Dmesg (diese Nachricht wird mehrmals wiederholt):

[35085.217154] ata10.00: exception Emask 0x0 SAct 0x2 SErr 0x0 action 0x0 [35085.217160] ata10.00: irq_stat 0x40000008 [35085.217163] ata10.00: failed command: READ FPDMA QUEUED [35085.217170] ata10.00: cmd 60/08:08:37:52:43/00:00:6d:00:00/40 tag 1 ncq 4096 in [35085.217170] res 41/40:00:3c:52:43/00:00:6d:00:00/40 Emask 0x409 (media error) <F> [35085.217173] ata10.00: status: { DRDY ERR } [35085.217175] ata10.00: error: { UNC } [35085.221619] ata10.00: configured for UDMA/133 [35085.221636] sd 9:0:0:0: [sdd] Unhandled sense code [35085.221639] sd 9:0:0:0: [sdd] [35085.221641] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [35085.221643] sd 9:0:0:0: [sdd] [35085.221645] Sense Key : Medium Error [current] [descriptor] [35085.221649] Descriptor sense data with sense descriptors (in hex): [35085.221651] 72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00 [35085.221661] 6d 43 52 3c [35085.221666] sd 9:0:0:0: [sdd] [35085.221669] Add. Sense: Unrecovered read error - auto reallocate failed [35085.221671] sd 9:0:0:0: [sdd] CDB: [35085.221673] Read(10): 28 00 6d 43 52 37 00 00 08 00 [35085.221682] end_request: I/O error, dev sdd, sector 1833128508 [35085.221706] ata10: EH complete 

mdadm detail:

sudo mdadm --detail /dev/md3 /dev/md3: Version : 1.2 Creation Time : Fri Apr 13 19:10:18 2012 Raid Level : raid1 Array Size : 976761382 (931.51 GiB 1000.20 GB) Used Dev Size : 976761382 (931.51 GiB 1000.20 GB) Raid Devices : 2 Total Devices : 2 Persistence : Superblock is persistent  Update Time : Wed Sep 4 08:57:46 2013 State : active, degraded, recovering Active Devices : 1 Working Devices : 2 Failed Devices : 0 Spare Devices : 1  Rebuild Status : 7% complete  Name : hypervisor:3 (local to host hypervisor) UUID : b758f8f1:a6a6862e:83133e3a:3b9830ea Events : 1257158  Number Major Minor RaidDevice State 2 8 49 0 active sync /dev/sdd1 3 8 33 1 spare rebuilding /dev/sdc1 

Eine Sache, die mir aufgefallen ist, ist, dass die Quellfestplatte (/ dev / sdd) eine Partition hat, die bei 63 beginnt, wo die neue Platte (/ dev / sdc) bei Sektor 2048 beginnt. Hat dies mit dem Problem zu tun? Gibt es eine Möglichkeit, mdadm mitzuteilen, diesen fehlerhaften Block zu ignorieren und den Array-Aufbau fortzusetzen? Als letzten Ausweg dachte ich daran, das Quelllaufwerk (/ dev / sdd) auf das neue Laufwerk (/ dev / sdc) mithilfe von ddrescue (livecd) zu klonen und dann dieses als Quelllaufwerk zu verwenden.

Danke für jede Hilfe. Yannis


Ich habe sowohl / dev / sdd als auch / sdc neu partitioniert. So sieht jetzt so aus:

sudo fdisk -l -u /dev/sdc  Disk /dev/sdc: 1000.2 GB, 1000204886016 bytes 81 heads, 63 sectors/track, 382818 cylinders, total 1953525168 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 4096 bytes Disk identifier: 0x0002c2de  Device Boot Start End Blocks Id System /dev/sdc1 2048 1953525167 976761560 da Non-FS data    sudo fdisk -l -u /dev/sdd  Disk /dev/sdd: 1000.2 GB, 1000204886016 bytes 23 heads, 12 sectors/track, 7077989 cylinders, total 1953525168 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytess Disk identifier: 0x00069b7e  Device Boot Start End Blocks Id System /dev/sdd1 2048 1953525167 976761560 da Non-FS data 

Ist das ok?


ok Ich baue das Array erneut auf und stelle dann alle Daten aus dem Backup wieder her. Alles sieht in Ordnung aus, außer dass beim Neustart / dev / md3 in / dev / md127 umbenannt wird.

 Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]  md127 : active raid1 sdd1[0] sdc1[2] 976630336 blocks super 1.2 [2/2] [UU]  md1 : active raid0 sdb5[0] sda5[1] 7809024 blocks super 1.2 512k chunks  md2 : active raid0 sdb6[0] sda6[1] 273512448 blocks super 1.2 512k chunks  md0 : active raid1 sdb1[0] sda1[2] 15623096 blocks super 1.2 [2/2] [UU]  cat /etc/mdadm/mdadm.conf ARRAY /dev/md/0 metadata=1.2 UUID=5c541476:4ee0d591:615c1e5a:d58bc3f7 name=hypervisor:0 ARRAY /dev/md/1 metadata=1.2 UUID=446ba1de:407f8ef4:5bf728ff:84e223db name=hypervisor:1 ARRAY /dev/md/2 metadata=1.2 UUID=b91cba71:3377feb4:8a57c958:11cc3df0 name=hypervisor:2 ARRAY /dev/md/3 metadata=1.2 UUID=5c573747:61c40d46:f5981a8b:e818a297 name=hypervisor:3  sudo mdadm --examine --scan --verbose ARRAY /dev/md/0 level=raid1 metadata=1.2 num-devices=2 UUID=5c541476:4ee0d591:615c1e5a:d58bc3f7 name=hypervisor:0 devices=/dev/sdb1,/dev/sda1 ARRAY /dev/md/1 level=raid0 metadata=1.2 num-devices=2 UUID=446ba1de:407f8ef4:5bf728ff:84e223db name=hypervisor:1 devices=/dev/sdb5,/dev/sda5 ARRAY /dev/md/2 level=raid0 metadata=1.2 num-devices=2 UUID=b91cba71:3377feb4:8a57c958:11cc3df0 name=hypervisor:2 devices=/dev/sdb6,/dev/sda6 ARRAY /dev/md/3 level=raid1 metadata=1.2 num-devices=2 UUID=5c573747:61c40d46:f5981a8b:e818a297 name=hypervisor:3 devices=/dev/sdd1,/dev/sdc1  cat /etc/fstab # /etc/fstab: static file system information. # # Use 'blkid' to print the universally unique identifier for a # device; this may be used with UUID= as a more robust way to name devices # that works even if disks are added and removed. See fstab(5). # # <file system> <mount point> <type> <options> <dump> <pass> proc /proc proc nodev,noexec,nosuid 0 0 # / was on /dev/md0 during installation UUID=2e4543d3-22aa-45e1-8adb-f95cfe57a697 / ext4 noatime,errors=remount-ro,discard 0 1 #was /dev/md3 before UUID=13689e0b-052f-48f7-bf1f-ad857364c0d6 /storage ext4 defaults 0 2 # /vm was on /dev/md2 during installation UUID=9fb85fbf-31f9-43ff-9a43-3ebef9d37ee8 /vm ext4 noatime,errors=remount-ro,discard 0 2 # swap was on /dev/md1 during installation UUID=1815549c-9047-464e-96a0-fe836fa80cfd none swap sw 

Irgendwelche Vorschläge dazu?

0
Ihre "gute" Fahrt ist eigentlich schlecht. Michael Hampton vor 11 Jahren 2

3 Antworten auf die Frage

2
MadHatter

Die gute Nachricht ist, dass ich immer noch Zugriff auf meine Daten haben kann, die in / storage gespeichert sind

Nein, das kannst du nicht. Sie haben ein Problem beim Lesen der Daten an diesen zwielichtigen Blöcken /dev/sdd. Sie wissen das im normalen Betrieb einfach nicht, entweder weil Sie diese Blöcke nicht lesen oder Ihre Anwendung Lesefehler toleriert.

Ich finde Nachrichten wie die, /dev/sdddie protokollieren, äußerst beunruhigend. Wenn es mein Gerät wäre, würde ich die Daten so schnell wie möglich sichern, vorzugsweise zweimal, das andere Laufwerk und auch das Laufwerk ersetzen und von einem solchen Backup wiederherstellen, das ich bekommen konnte.

Außerdem versuchen Sie, wie Sie darauf hinweisen, eine 976762552-Blockpartition mit einer 976761560-Blockpartition zu spiegeln, und das funktioniert nicht. Die neue Partition muss mindestens so groß sein wie die alte. Ich bin etwas überrascht, dass mdadmdie Rekonstruktion fortgesetzt werden konnte, aber Sie sagen nicht, welche Distribution Sie betreiben. Daher ist es schwierig zu wissen, wie alt die Version ist. Vielleicht ist es alt genug, so etwas nicht zu überprüfen.

Bearbeiten : Ja, Sie sollten die Partition wie beschrieben vergrößern. Ich bin kein Ubuntu-Fan und kann diese Version nicht kommentieren. Wenn Sie diese Resynchronisation abgeschlossen haben, würde ich das andere Laufwerk sofort austauschen. Bei einer anständigen Sicherung würde ich keine Zeit mehr für die Neusynchronisierung aufwenden, sie jetzt ersetzen, das Array neu erstellen und aus Sicherungen wiederherstellen.

Ich habe Ubuntu 12.04 x64: uname -a Linux-Hypervisor 3.8.0-29-generic # 42 ~ exact1-Ubuntu SMP Mi Aug 14 16:19:23 UTC 2013 x86_64 x86_64 x86_64 Ich habe bereits alle Daten gesichert Ich muss den Wiederaufbauprozess abschließen lassen. Wie gesagt, eine der beiden Festplatten ist brandneu. Wenn ich fdisk (ed) habe, ordnete fdisk automatisch den ersten Sektor bei 2048 (statt 63) ein. Soll ich die Partition manuell löschen und statt 2048 63 setzen? vor 11 Jahren 0
1
Community

Sie können das hier beschriebene Verfahren versuchen: Entfernen Sie SW RAID1 von einer neuen Festplatte und einer alten Festplatte mit fehlerhaften Blöcken . Es verwendet hdparm, um fehlerhafte Sektoren zu lesen und zu schreiben und sie, falls möglich, auf der Festplatte neu zuzuordnen.

0
GioMac

Das sdd-Laufwerk ist definitiv ausgefallen und hat keinen internen Platz für die Neuzuweisung.

Sie können trotzdem versuchen, die Firmware zu aktualisieren, falls verfügbar.

BTW, das sind GPT - Datenträger, Verwendung partedoder gdiskfür das Auflisten und die Manipulation von Partitionen. fdisk unterstützt GPT nicht und ist global sehr fehlerhaft.