Ich sehe nun, was das Problem ist. Der Cache macht probleme. Das könnte ein RMA sein :-) Die /dev/sda ist meine Linux Installation (neue Platte des HP) Es stellt sich nun die Frage, ob ich einfach wieder eine solche Platte bestelle oder auf 24/7 Platten wechsle. Wenn, dann gehe ich, glaube, auf WD Red (evtl. Pro). Die haben aber ein LCC Problem, das man mit Software lösen kann. Was meinst Du? yoda:~ # smartctl -H /dev/sdc smartctl 6.2 2013-11-07 r3856 [x86_64-linux-4.4.70-18.9-default] (SUSE RPM) Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED Please note the following marginal Attributes: ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE 184 End-to-End_Error 0x0032 099 099 099 Old_age Always FAILING_NOW 1 yoda:~ # smartctl -H /dev/sdb smartctl 6.2 2013-11-07 r3856 [x86_64-linux-4.4.70-18.9-default] (SUSE RPM) Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED yoda:~ # smartctl -H /dev/sda smartctl 6.2 2013-11-07 r3856 [x86_64-linux-4.4.70-18.9-default] (SUSE RPM) Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org === START OF READ SMART DATA SECTION === SMART overall-health self-assessment test result: PASSED Danke noch mal, Lothar Am 16.06.2017 um 23:07 schrieb Christian Boltz:
Hallo Lothar, hallo zusammen,
Am Freitag, 16. Juni 2017, 21:47:32 CEST schrieb Lothar Behrens:
heute habe ich endlich meinen neuen Server vollständig installiert - denke ich.
Server: HP ProLiant ML10 Xeon OS: openSUSE Leap 42 Platten: Leider noch Desktop Seagate Modelle (verwende noch die vom alten / sind etwa 2 Jahre alt)
Nun muss ich sehen, dass ich ein DegradedArray habe. Ich kann nicht sagen, ob das noch in dem alten Server vor dem Umbau in den neuen Server so war. (Habe die alten Mails nicht gefunden / müssen aber auf den Platten sein)
Das spricht dafür, dass das RAID schon länger degraded ist.
Wenn es richtig blöd gelaufen ist (habe ich vor ein paar Jahren mal erlebt), sind prinzipiell beide Platten in Ordnung, "nur" das RAID hat sich geteilt und schlimmstenfalls wird beim Booten mehr oder weniger zufällig ausgewählt, welche der Platten denn heute arbeiten darf. Ergebnis wären unterschiedliche Datenbestände auf den Platten.
Das ist wie gesagt das schlimmste Szenario und ich hoffe, dass das nicht Dein Problem ist. Trotzdem solltest Du mal beide Platten _getrennt_ mounten (dafür musst Du die derzeit unbenutzte Platte in ein eigenes md-Device packen - IIRC mit mdadm --assemble /dev/md42 /dev/sda2 missing (bitte nochmal in der Manpage nachlesen und prüfen, bevor Du es tatsächlich ausführst! - und natürlich auch /dev/sda2 passend ändern)
Dann md42 irgendwohin mounten und mit md127 vergleichen (z. B. mit diff -r oder rsync --dry-run), ob/wo es Unterschiede gibt.
Unnötig zu sagen: das solltest Du machen, bevor Du das RAID wieder zusammensetzt - hinterher sind beide Platten wieder gleich ;-)
Wirf auch mal einen Blick auf https://raid.wiki.kernel.org/index.php/RAID_Recovery mdadm --examinate könnte z. B. hilfreiche Infos liefern.
Warum geht die Platte temporär auf Readonly?
Bist Du sicher, dass sie das macht? (Logeinträge?)
Wie finde ich heraus, was die Platte hat?
Ich würde einen Blick in /var/log/messages empfehlen. (Wenn Du das auf beiden Platten machst, bekommst Du auch einen schnellen Überblick, welche zu welchem Zeitpunkt aktiv war.)
PS: Ich hatte ein Problem mit meiner Onboard Netzwerk Karte e1000e in einem Sleep Mode des Prozessors. Dafür gab es einen Fix, den ich eingerichtet habe.
Kann es sein, dass die Platten auch in den Sleep mode gehen / es damit zusammen hängt?
Nichts ist unmöglich, aber ich halte es für unwahrscheinlich.
Gruß
Christian Boltz
Wie behebt man wohl das Problem einer vollen Mailbox? Ist das eine ernstgemeinte Frage von Dir? Wie waere es mal mit Emails loeschen? Bin ich hier bei versteckter Kamera gelandet? Ich fasse es nicht... [Thomas Hertweck (zu Thomas Hille) in suse-linux]
-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org