EG
thinking with portals
|
Hab grad am PC gearbeitet und Musik (smb share) gehört, die plötzlich verstummt ist. Auf meine VM(ware) kann ich ebenfalls nicht mehr zugreifen...kein wunder, WEIL: root@filer:/mnt/lvmraid5# mdadm --detail /dev/md0
/dev/md0:
Version : 00.90
Creation Time : Fri Jan 15 01:13:23 2010
Raid Level : raid5
Array Size : 5860543488 (5589.05 GiB 6001.20 GB)
Used Dev Size : 1465135872 (1397.26 GiB 1500.30 GB)
Raid Devices : 5
Total Devices : 5
Preferred Minor : 0
Persistence : Superblock is persistent
Update Time : Wed Oct 20 13:20:09 2010
State : clean, degraded
Active Devices : 3
Working Devices : 3
Failed Devices : 2
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 256K
UUID : aa6fd5f5:fdbfaba3:7cc4f564:e0529720 (local to host filer)
Events : 0.7206192
Number Major Minor RaidDevice State
0 8 17 0 active sync /dev/sdb1
1 0 0 1 removed
2 8 33 2 active sync /dev/sdc1
3 8 65 3 active sync /dev/sde1
4 0 0 4 removed
5 8 81 - faulty spare /dev/sdf1
6 8 49 - faulty spare /dev/sdd1
Das plötzlich der Fall ist. Was mich in mehrfacher Hinsicht verwirrt, weils raid noch immer clean ist? edit: Ich komm auch zumindest per shell noch auf die Daten...
|
COLOSSUS
AdministratorGNUltra
|
Was mit den Platten passiert ist, weisz der Kernel -> dmesg.
Viel machen wuerde ich auf dem FS nicht mehr (bevor das Array nicht wieder steht), wenn dir die Daten lieb sind. "Clean" bedeutet nur, dass kein resync geplant ist.
# mdadm --re-add /dev/md- /dev/sdf1 /dev/sdd1
schon versucht?
|
EG
thinking with portals
|
Hab noch nix am raid versucht, wollt mich erst informieren. Machts sinn das Filesystem auszuhängen, oder fördert das bei mdadm schlechte Nebenwirkungen? Hier mal /var/log/messages: Oct 19 22:14:03 filer kernel: [1147747.011385] ata6: hard resetting link
Oct 19 22:14:13 filer kernel: [1147757.030053] ata6: hard resetting link
Oct 19 22:14:23 filer kernel: [1147767.040083] ata6: hard resetting link
Oct 19 22:14:33 filer kernel: [1147777.650046] ata6: link is slow to respond, please be patient (ready=0)
Oct 19 22:14:58 filer kernel: [1147802.070073] ata6: limiting SATA link speed to 1.5 Gbps
Oct 19 22:14:58 filer kernel: [1147802.070080] ata6: hard resetting link
Oct 19 22:15:03 filer kernel: [1147807.300079] ata6.00: disabled
Oct 19 22:15:03 filer kernel: [1147807.300101] ata6: EH complete
Oct 19 22:15:03 filer kernel: [1147807.300149] sd 5:0:0:0: [sdf] Unhandled error code
Oct 19 22:15:03 filer kernel: [1147807.300153] sd 5:0:0:0: [sdf] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
Oct 19 22:15:03 filer kernel: [1147807.300162] sd 5:0:0:0: [sdf] CDB: Write(10): 2a 00 ae a8 66 bf 00 00 08 00
Oct 19 22:15:03 filer kernel: [1147807.300205] md: super_written gets error=-5, uptodate=0
Oct 19 22:15:03 filer kernel: [1147807.408285] RAID5 conf printout:
Oct 19 22:15:03 filer kernel: [1147807.408294] --- rd:5 wd:4
Oct 19 22:15:03 filer kernel: [1147807.408301] disk 0, o:1, dev:sdb1
Oct 19 22:15:03 filer kernel: [1147807.408306] disk 1, o:1, dev:sdd1
Oct 19 22:15:03 filer kernel: [1147807.408310] disk 2, o:1, dev:sdc1
Oct 19 22:15:03 filer kernel: [1147807.408314] disk 3, o:1, dev:sde1
Oct 19 22:15:03 filer kernel: [1147807.408318] disk 4, o:0, dev:sdf1
Oct 19 22:15:03 filer kernel: [1147807.430052] RAID5 conf printout:
Oct 19 22:15:03 filer kernel: [1147807.430061] --- rd:5 wd:4
Oct 19 22:15:03 filer kernel: [1147807.430067] disk 0, o:1, dev:sdb1
Oct 19 22:15:03 filer kernel: [1147807.430072] disk 1, o:1, dev:sdd1
Oct 19 22:15:03 filer kernel: [1147807.430076] disk 2, o:1, dev:sdc1
Oct 19 22:15:03 filer kernel: [1147807.430080] disk 3, o:1, dev:sde1
Oct 20 01:54:41 filer kernel: [1160984.704115] usb 1-4: USB disconnect, address 2
Oct 20 01:54:41 filer kernel: [1160985.020075] usb 1-4: new high speed USB device using ehci_hcd and address 3
Oct 20 01:54:41 filer kernel: [1160985.174701] usb 1-4: configuration #1 chosen from 1 choice
Oct 20 06:47:46 filer rsyslogd: [origin software="rsyslogd" swVersion="4.2.0" x-pid="1121" x-info="http://www.rsyslog.com"] rsyslogd was HUPed, type 'lightweight'.
Oct 20 06:47:46 filer rsyslogd: [origin software="rsyslogd" swVersion="4.2.0" x-pid="1121" x-info="http://www.rsyslog.com"] rsyslogd was HUPed, type 'lightweight'.
Oct 20 12:38:29 filer kernel: [1199613.477366] usb 4-3: USB disconnect, address 50
Oct 20 12:38:30 filer kernel: [1199613.811691] usb 4-3: new low speed USB device using ohci_hcd and address 51
Oct 20 12:38:30 filer kernel: [1199614.070337] usb 4-3: configuration #1 chosen from 1 choice
Oct 20 12:38:30 filer kernel: [1199614.391466] generic-usb 0003:051D:0002.0032: hiddev96,hidraw0: USB HID v1.10 Device [APC Back-UPS ES 550G FW:870.O1 .I USB FW:O1 ] on usb-0000:00:04.0-3/input0
Oct 20 13:11:41 filer kernel: [1201605.216145] ata4.00: configured for UDMA/133
Oct 20 13:11:41 filer kernel: [1201605.216206] ata4: EH complete
Oct 20 13:11:44 filer kernel: [1201607.901595] ata4.00: configured for UDMA/133
Oct 20 13:11:44 filer kernel: [1201607.901625] ata4: EH complete
Oct 20 13:11:46 filer kernel: [1201610.423750] ata4.00: configured for UDMA/133
Oct 20 13:11:46 filer kernel: [1201610.423778] ata4: EH complete
Oct 20 13:11:49 filer kernel: [1201613.066554] ata4.00: configured for UDMA/133
Oct 20 13:11:49 filer kernel: [1201613.066584] ata4: EH complete
Oct 20 13:11:52 filer kernel: [1201615.796883] ata4.00: configured for UDMA/133
Oct 20 13:11:52 filer kernel: [1201615.796912] ata4: EH complete
Oct 20 13:11:54 filer kernel: [1201618.285882] ata4.00: configured for UDMA/133
Oct 20 13:11:54 filer kernel: [1201618.285958] sd 3:0:0:0: [sdd] Unhandled sense code
Oct 20 13:11:54 filer kernel: [1201618.285963] sd 3:0:0:0: [sdd] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Oct 20 13:11:54 filer kernel: [1201618.285971] sd 3:0:0:0: [sdd] Sense Key : Medium Error [current] [descriptor]
Oct 20 13:11:54 filer kernel: [1201618.285981] Descriptor sense data with sense descriptors (in hex):
Oct 20 13:11:54 filer kernel: [1201618.285986] 72 03 11 04 00 00 00 0c 00 0a 80 00 00 00 00 00
Oct 20 13:11:54 filer kernel: [1201618.286004] 82 6e e3 ff
Oct 20 13:11:54 filer kernel: [1201618.286012] sd 3:0:0:0: [sdd] Add. Sense: Unrecovered read error - auto reallocate failed
Oct 20 13:11:54 filer kernel: [1201618.286021] sd 3:0:0:0: [sdd] CDB: Read(10): 28 00 82 6e e2 47 00 02 80 00
Oct 20 13:11:54 filer kernel: [1201618.286047] raid5:md0: read error not correctable (sector 2188305344 on sdd1).
Oct 20 13:11:54 filer kernel: [1201618.286514] raid5:md0: read error not correctable (sector 2188305352 on sdd1).
Oct 20 13:11:54 filer kernel: [1201618.286521] raid5:md0: read error not correctable (sector 2188305360 on sdd1).
Oct 20 13:11:54 filer kernel: [1201618.286528] raid5:md0: read error not correctable (sector 2188305368 on sdd1).
Oct 20 13:11:54 filer kernel: [1201618.286535] raid5:md0: read error not correctable (sector 2188305376 on sdd1).
Oct 20 13:11:54 filer kernel: [1201618.286541] raid5:md0: read error not correctable (sector 2188305384 on sdd1).
Oct 20 13:11:54 filer kernel: [1201618.286548] raid5:md0: read error not correctable (sector 2188305392 on sdd1).
Oct 20 13:11:54 filer kernel: [1201618.286555] raid5:md0: read error not correctable (sector 2188305400 on sdd1).
Oct 20 13:11:54 filer kernel: [1201618.286561] raid5:md0: read error not correctable (sector 2188305408 on sdd1).
Oct 20 13:11:54 filer kernel: [1201618.286568] raid5:md0: read error not correctable (sector 2188305416 on sdd1).
Oct 20 13:11:54 filer kernel: [1201618.286632] ata4: EH complete
Oct 20 13:11:55 filer kernel: [1201618.911030] RAID5 conf printout:
Oct 20 13:11:55 filer kernel: [1201618.911040] --- rd:5 wd:3
Oct 20 13:11:55 filer kernel: [1201618.911047] disk 0, o:1, dev:sdb1
Oct 20 13:11:55 filer kernel: [1201618.911053] disk 1, o:0, dev:sdd1
Oct 20 13:11:55 filer kernel: [1201618.911057] disk 2, o:1, dev:sdc1
Oct 20 13:11:55 filer kernel: [1201618.911061] disk 3, o:1, dev:sde1
Oct 20 13:11:55 filer kernel: [1201618.930082] RAID5 conf printout:
Oct 20 13:11:55 filer kernel: [1201618.930092] --- rd:5 wd:3
Oct 20 13:11:55 filer kernel: [1201618.930099] disk 0, o:1, dev:sdb1
Oct 20 13:11:55 filer kernel: [1201618.930104] disk 2, o:1, dev:sdc1
Oct 20 13:11:55 filer kernel: [1201618.930108] disk 3, o:1, dev:sde1
Oct 20 13:12:00 filer kernel: [1201624.097046] __ratelimit: 27 callbacks suppressed
Oct 20 13:12:00 filer kernel: [1201624.097062] lost page write due to I/O error on dm-0
Oct 20 13:18:16 filer /usr/lib/vmware/bin/vmware-hostd[3937]: Accepted password for user tom from 127.0.0.1
Oct 20 13:25:23 filer kernel: [1202426.697933] usb 1-4: USB disconnect, address 3
Oct 20 13:41:21 filer kernel: [1203384.990513] sd 5:0:0:0: [sdf] Unhandled error code
Oct 20 13:41:21 filer kernel: [1203384.990521] sd 5:0:0:0: [sdf] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
Oct 20 13:41:21 filer kernel: [1203384.990530] sd 5:0:0:0: [sdf] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00
Oct 20 13:41:21 filer kernel: [1203384.990580] sd 5:0:0:0: [sdf] Unhandled error code
Oct 20 13:41:21 filer kernel: [1203384.990584] sd 5:0:0:0: [sdf] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
Oct 20 13:41:21 filer kernel: [1203384.990591] sd 5:0:0:0: [sdf] CDB: Read(10): 28 00 00 00 00 08 00 00 18 00
Oct 20 13:41:21 filer kernel: [1203384.990653] sd 5:0:0:0: [sdf] Unhandled error code
Oct 20 13:41:21 filer kernel: [1203384.990657] sd 5:0:0:0: [sdf] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
Oct 20 13:41:21 filer kernel: [1203384.990664] sd 5:0:0:0: [sdf] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00
Oct 20 13:41:21 filer kernel: [1203384.990749] sd 5:0:0:0: [sdf] Unhandled error code
Oct 20 13:41:21 filer kernel: [1203384.990753] sd 5:0:0:0: [sdf] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
Oct 20 13:41:21 filer kernel: [1203384.990760] sd 5:0:0:0: [sdf] CDB: Read(10): 28 00 ae a8 7b 28 00 00 08 00
Oct 20 13:41:21 filer kernel: [1203384.990809] sd 5:0:0:0: [sdf] Unhandled error code
Oct 20 13:41:21 filer kernel: [1203384.990813] sd 5:0:0:0: [sdf] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
Oct 20 13:41:21 filer kernel: [1203384.990819] sd 5:0:0:0: [sdf] CDB: Read(10): 28 00 ae a8 7b 28 00 00 08 00
Oct 20 13:41:21 filer kernel: [1203384.990888] sd 5:0:0:0: [sdf] Unhandled error code
Oct 20 13:41:21 filer kernel: [1203384.990893] sd 5:0:0:0: [sdf] Result: hostbyte=DID_BAD_TARGET driverbyte=DRIVER_OK
Oct 20 13:41:21 filer kernel: [1203384.990900] sd 5:0:0:0: [sdf] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00
dmesg: Als File, da oc.at scheinbar Probleme mit glossary-Begriffen in code-Tags hat: click hereedit: root@filer:/# mdadm --re-add /dev/md0 /dev/sdf1 /dev/sdd1
mdadm: Cannot open /dev/sdf1: Device or resource busy
|
COLOSSUS
AdministratorGNUltra
|
Das sieht nicht gut aus. Zumindest eine der Platten duerfte Toast sein, warum die zweite (deshalb?) auch in der Luft haengt, kann ich auf die Schnelle nicht sagen. Ich wuerde das System runterfahren und die kaputten Disks auf einem Fremdsystem auf ein anderes Medium rausdumpen, als allerersten Schritt.
|
EG
thinking with portals
|
Kann mir ganz ehrlich ned vorstellen, dass beide Platten kaputt sind...wäre doch zuviel des Zufalls. Hab das hier gefunden: http://kevin.deldycke.com/2008/07/h...-data-recovery/Angenommen eine der Platten funktioniert noch...wärs sdd oder sdf? Werd ehrlichgesagt ned recht schlau aus dem dmesg output. Für mich siehts so aus als hätte sdf Probleme an der Schnittstelle? edit: Was mich am meisten wundert ist, dass ich noch auf die Daten zugreifen kann? Zumindest per Shell...werd wohl mal die wichtigen Daten per USB-Quickport sichern. Ein dump der großen Datenmengen ist nicht möglich. Das Raid hat 5,6TB. edit: soll heißen -> ich hab einen quick port und ein paar ältere 1TB Platten rumliegen. Die wichtigsten Daten und Dokumente passen da drauf. Lesbar sind die Daten ja noch, zumindest langsam und teilweise. Wäre es sinnvoll es fs vorher read only zu mounten? edit2: Hat sich erledigt, es sind nur sehr wenige Daten noch intakt und kopierbar. Hab mir zumindest mal die Verzeichnisstrukturen ziehen können, um später nachzuvollziehen wieviel fehlt. Das Meiste sollten ohnehin eher unwichtige Daten sein, die wiederbeschaffbar sind. smartctl sagt auf jedenfall, dass sdf nicht auslesbar ist.
|
EG
thinking with portals
|
Naja ist wohl nichts zu machen...hab bissi drauf rumgehackt, hat aber nix gebracht.
Am schmerzlichsten sind die Fotos...der Rest liegt irgendwo anders auch noch. Zumindest eine Liste aller Dateien konnte ich mir noch ziehen. Somit weiß ich, was alles weg ist.
Werd mir jetzt wohl einen Raidcontroller zulegen...das ewige Herumgetue hat in den letzten Monaten echt viel Zeit gekostet und in den Verlust aller Daten gegipfelt. Nachdem ich nedmal weiß wieso das passiert ist und es sich auch ned nachvollziehen lässt, mag ich einfach nicht mehr.
|
EG
thinking with portals
|
Gäbe es eine disaster recovery Möglichkeit fürs Raid?
Z.B. mit tools nach files auf den einzelnen Platten suchen? Die Daten werden ja grundsätzlich nacheinander auf der selben Platte abgelegt, während nur die Paritätsinfos verteilt sind, oder?
|
Ringding
Pilot
|
Kann mir ganz ehrlich ned vorstellen, dass beide Platten kaputt sind...wäre doch zuviel des Zufalls. Naja wann hast du denn das letzte Mal reingeschaut? Die eine Platte könnte ja auch schon seit Monaten hin sein, sodass du in letzter Zeit unwissend mit einem RAID-0 gefahren bist.
|
EG
thinking with portals
|
Das letzte Mal...3-4 Tage...vielleicht ne Woche. An sich schreibt mir mein Server ja ne Mail...hat er diesmal aber nicht! 
|
COLOSSUS
AdministratorGNUltra
|
Ich kann dir nur sagen, dass ein "Hardware-RAID"-Controller dich nicht besser haette aussteigen lassen, wenn ihm zwei Platten innerhalb kurzer Zeit sagen "herst, ich bin hin!".
Der Inhalt des Kernel Debug Ringbuffer laesst mich jedenfalls die folgenden Schluesse ziehen:
o) ata6.00 hatte ein Problem beim abarbeiten eines (via NCQ) abzuarbeitenden ATA-Kommandos - diversen Google-Suchtreffern zu Folge passiert das ab und an, wenn ein IRQ - aus welchen Gruenden auch immer - "verschluckt" wird.
o) libata hat daraufhin den entsprechenden SATA-Port reinitialisiert, was normalerweise ueberhaupt kein Problem ist.
o) Deiner Platte gefiel das ueberhaupt nicht, und nicht mal beim Auslesen der Partitionstabelle wollte sie noch mitspielen.
Daraufhin fiel dem Kernel auf, dass dein vmware Server schon seit 120 Sekunden auf seinen I/O-Request wartet, und er hat deswegen erst einmal eine freundliche Warnung (mit Trace) ausgegeben. Auf Systemen mit extrem hoher I/O-Load sieht man sowas oefters, wie ich dir aus Erfahrung sagen kann. Bei dir war das Problem allerdings, dass (der) I/O-Request(s) gegen ein "totes" Device gefahren wurden. libata hatte aber noch nicht vollstaendig aufgegeben, und hat das oben beschriebene Spiel noch ein bisschen wiederholt, bis dann in Zeile 101 etwas nicht Unerwartetes passiert:
o) sdf (das ist der Device Node von ata6:00) wird vom Kernel endgueltig abgeschrieben, md erkennt das, und faehrt das Array degraded weiter. Alles nach Plan. Wenn dein Monitoring korrekt eingerichtet gewesen waere, haettest Du das sofort per Mail oder Programmaufruf mitgeteilt bekommen. Wie viel das allerdings nach den noch folgenden ungluecklichen Entwicklungen geholfen haette, ist fraglich.
o) 220 Minuten nach dem (Schein-)Tod von sdf verabschiedet sich kurz die USB-Verbindung zur USV. Das ist nicht ungewoehnlich, weil USB einfach ein billiger Dreck ist, und bringt ein korrekt konfiguriertes System nicht aus dem Tritt - es sei denn, es ist uebernervoes konfiguriert, und schaltet bei Unterbrechung des Datenkanalös zur USV sofort ab. Hat deines nicht, ist auch gut so.
o) Weitere elf Stunden nach diesem Ereignis kriegt ploetzlich die zweite Platte Schluckauf - und das deutlich heftiger als die erste. Zeile 192 zeigt deutlich, dass die Firmware der Platte meldet (wiederholt - so lange, bis der Block Layer genug von diesem Lied hat), einen Sektor nicht mehr lesen zu koennen. Das Standardverhalten von md ist dabei, die Platte aus dem Array abzumelden, da einer sterbenden Disk nicht zu trauen ist. Dein Array lebt noch auf 3 von 5 Disken weiter, was OK sein sollte, so lange nicht geschrieben wird (und man eine der fehlenden wiederherstellen kann).
o) ext4 reagiert richtig, und remountet sich read-only. Man kann dem fs beim Mounten mitteilen, dass es in einem solchen Fall einen Kernel Panic lostreten soll. Ob das etwas besser gemacht haette ist fraglich, aber diskutierbar.
o) Nachdem dem md-Blockdevice ein Viertel seiner Netto-Storage aus dem Herzen gerissen wurde, gehen in weiterer Folge einige Block-Read-Reuqests ins Leere. Bitter, aber ob der Umstaende zu erwarten. Dem FS und den Daten auf der Platte jedenfalls schadet das nicht mehr, da das ja bereits alles read-only ist.
Das Log endet damit, dass noch einige Block Read Requests gegen sdf gefahren werden (die erste Platte, die du verloren hast). Welchen Hintergrund das genau hat, kann ich dir nicht erklaeren. Haettest du aber das mehr als vierzehnstuendige Zeitfenster genutzt, um dich um dein degradetes Array entsprechend zu kuemmern (wenn du es denn ueberhaupt mitgekriegt haettest - ich krieg in so einem Fall eine Shortmessage aufs Handy und eine E-Mail in meinen ALERTS-Folder, auch privat), haettest du deine Fotos wohl noch. Tough luck, mein Beileid.
Wenn du es schaffst, md zum Assemblen des Arrays aus den drei funktionierenden Platten und der alten sdf zu bringen, hast du evtl. eine Chance, deine Daten zurueckzubekommen. Dem fs darauf selbst duerfte jedenfalls nicht allzu viel passiert sein.
|
EG
thinking with portals
|
Ich hab das Raid mit --create --assume-clean soweit hinbekommen, dass es wieder da steht wo es stehen soll...nämlich mit sdf missing!
Leider erkennt er am md0 keinen Superblock? Bei einem Scan spuckt er beide (das alte und das neue) Raid5 aus...
Bin aber irgendwie zu genervt von dem Ganzen heute als dass ich mich da weiter spiel.
Wenn du noch eine Idee hast wie ich das Raid zumindest degraded wieder hoch bring, damit ich Daten runterziehen kann, wär mir schon sehr geholfen.
|
COLOSSUS
AdministratorGNUltra
|
Nachdem create einen neuen Superblock schreibt, sind die Daten auf deinem Array zwar noch vorhanden, der Superblock ist aber "fabrikneu", und hat nichts mehr mit deinem alten Array zu tun. Jetzt kann es durchaus sein, dass du - wenn kein resync passiert ist - irgendwie die LVM-Metadaten auf dem lockdev wieder registrieren kannst, dann dein LV daraus aktiv setzen und das FS darauf mounten - das ganze wird aber tricky. Ein schoenes Nachmittagsprojekt mindestens, nehme ich an.
|
EG
thinking with portals
|
Ich hab mich jetzt bissl reingehackt, bekomm aber - für meine Verhältnisse - keinen sinnvollen output raus. root@filer:~# mdadm --assemble /dev/md0 --auto yes --scan --update=summaries --verbose
mdadm: looking for devices for /dev/md0
mdadm: /dev/sdc1 requires wrong number of drives.
mdadm: /dev/sdc has wrong uuid.
mdadm: cannot open device /dev/sde1: Device or resource busy
mdadm: /dev/sde1 has wrong uuid.
mdadm: cannot open device /dev/sde: Device or resource busy
mdadm: /dev/sde has wrong uuid.
mdadm: cannot open device /dev/sdd1: Device or resource busy
mdadm: /dev/sdd1 has wrong uuid.
mdadm: cannot open device /dev/sdd: Device or resource busy
mdadm: /dev/sdd has wrong uuid.
mdadm: /dev/sdf1 requires wrong number of drives.
mdadm: no RAID superblock on /dev/sdf
mdadm: /dev/sdf has wrong uuid.
mdadm: /dev/sdb1 requires wrong number of drives.
mdadm: /dev/sdb has wrong uuid.
mdadm: cannot open device /dev/sda5: Device or resource busy
mdadm: /dev/sda5 has wrong uuid.
mdadm: no RAID superblock on /dev/sda2
mdadm: /dev/sda2 has wrong uuid.
mdadm: cannot open device /dev/sda1: Device or resource busy
mdadm: /dev/sda1 has wrong uuid.
mdadm: cannot open device /dev/sda: Device or resource busy
mdadm: /dev/sda has wrong uuid.
mdadm: no devices found for /dev/md0
root@filer:~# mdadm --examine --scan
ARRAY /dev/md0 level=raid5 num-devices=5 UUID=6700739a:fe2f06c0:7cc4f564:e0529720
ARRAY /dev/md0 level=raid5 num-devices=5 UUID=aa6fd5f5:fdbfaba3:7cc4f564:e0529720
root@filer:~# mdadm --detail /dev/md0
mdadm: cannot open /dev/md0: No such file or directory
root@filer:~# ls /dev/md*
/dev/md_d0 /dev/md_d0p1 /dev/md_d0p2 /dev/md_d0p3 /dev/md_d0p4
/dev/md:
d0 d0p1 d0p2 d0p3 d0p4
Woher plötzlich diese d0p? devices kommen, ist mir auch ein rätsel...google spuckt da nix sinnvolles aus. Nachdem ich gestern den Server runtergefahren hab und heute wieder angefangen, findet er beide (das alte und das neue raid) mittels "mdadm --examine --scan". Starte ich, steht das alte Raid da. Momentan ist garkein md0 vorhanden (nach einem stop mit -S)...nur die oben gelisteten. Ergo kann ichs auch nicht starten. Übersteigt mein wissen über software raids halt gröber, nachdem das der erste Versuch war. Man muss schon auch anmerken, dass mdadm wirklich bescheiden dokumentiert ist und es tausend Probleme und kaum bis keine Lösungen gibt...immer wieder find ich Foren, wo User Probleme haben, auf die irgendwelche unspezifizierten Antworten kommen und im Endeffekt der Thread einfach aufhört, weil wohl der Threadstarter aufgegeben hat. Wenn ich jetzt wieder mit --create --assume-clean versuche das Raid zusammenzubauen, krieg ich warscheinlich ein 3. array? Machen mich 2 schon sehr unschlüssig... edit: Ich würd ihn gern zwingen, dass er das Raid einfach zusammenbaut und so ansieht, als wärs bei dem Zeitpunkt wo nur eine der beiden Platten degraded ist. AUßERDEM sind jetzt wieder alle Platten ansprechbar und haben Health-Status "PASSED" bei Abfrage mittels smartctl.
|
COLOSSUS
AdministratorGNUltra
|
edit: Ich würd ihn gern zwingen, dass er das Raid einfach zusammenbaut und so ansieht, als wärs bei dem Zeitpunkt wo nur eine der beiden Platten degraded ist. Das ist mir durchaus klar, nur fuerchte ich, dass du diese Chance mit dem voreiligen Ueberschreiben des Superblocks (durch mdadm --create...) verspielt hast. Frag einfach auf der linux-raid mailing list, wie du am besten vorgehst. Neil Brown, der mdadm- und md-Maintainer, ist ein sehr hilfsbereiter Kerl, der vermutlich auch zu deiner verfahrenen Situation etwas Nuetzliches beitragen kann. Die bei dir entstehenden Device Nodes deuten meines Wissen nach darauf hin, dass dein neues Array partitionierbar ist, und irgendwie wohl auch partitioniert wurde. Uebrigens finde ich die manpage von mdadm wirklich nicht schlecht. Hier zu schimpfen ist wirklich nicht angebracht; schau mal in das Handbuch eines beliebigen RAID-Controllers in feinstem Chinenglish und vergleiche...
|
EG
thinking with portals
|
Frag mich nicht wieso... Raid war da mit 3 faulties...ich hab einfach --add der 3 fehlenden. ZACK alles war wieder da! root@filer:~# pvdisplay /dev/md0
--- Physical volume ---
PV Name /dev/md0
VG Name lvm-raid
PV Size 5,46 TiB / not usable 2,81 MiB
Allocatable yes (but full)
PE Size 4,00 MiB
Total PE 1430796
Free PE 0
Allocated PE 1430796
PV UUID 8dGEC3-kjHI-0grv-cNaQ-hcru-IYWw-h2C7lQ
root@filer:~# mount /mnt/lvmraid5/
root@filer:/mnt/lvmraid5# mdadm --detail /dev/md0
/dev/md0:
Version : 00.90
Creation Time : Fri Jan 15 01:13:23 2010
Raid Level : raid5
Array Size : 5860543488 (5589.05 GiB 6001.20 GB)
Used Dev Size : 1465135872 (1397.26 GiB 1500.30 GB)
Raid Devices : 5
Total Devices : 5
Preferred Minor : 0
Persistence : Superblock is persistent
Update Time : Thu Oct 21 20:02:45 2010
State : clean
Active Devices : 5
Working Devices : 5
Failed Devices : 0
Spare Devices : 0
Layout : left-symmetric
Chunk Size : 256K
UUID : aa6fd5f5:fdbfaba3:7cc4f564:e0529720 (local to host filer)
Events : 0.7206216
Number Major Minor RaidDevice State
0 8 17 0 active sync /dev/sdb1
1 8 49 1 active sync /dev/sdd1
2 8 33 2 active sync /dev/sdc1
3 8 65 3 active sync /dev/sde1
4 8 81 4 active sync /dev/sdf1
wtF?? edit: Bin grad dabei meine Daten die ich ned gebackupt habe runterzukopieren...was sollte der logisch nächste Schritt sein, ohne inversiv auf das fs zuzugreifen? fsck.ext4?
|
Anmeldung