Hallo,
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)
Warum geht die Platte temporär auf Readonly?
Wie finde ich heraus, was die Platte hat?
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?
Danke für Eure Hilfe!
Erste Mail:
Date: Fri, 16 Jun 2017 18:15:01 +0200 (CEST)
From: mdadm monitoring
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
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
Am 17.06.2017 um 12:50 schrieb Lothar Behrens:
Ich sehe nun, was das Problem ist. Der Cache macht probleme. Das könnte ein RMA sein :-) Das kann aber auch durch ein SATA Kabelproblem verursacht werden.
"End-to-End error S.M.A.R.T. parameter is a part of HP's SMART IV technology and it means that after transferring through the cache RAM data buffer, the parity data between the host and the hard drive did not match. For detailed information see " Aber auch hier gilt, nichts genaues weiß man nicht, wie so oft bei den Smart Werten Gruß Manfred -- 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
@Manfred: Sorry :-) Die Platte habe ich aus meinem alten Server in eine komplett neue HP ProLiant ML10 Kiste verbaut. Die Fehler des RAID (1 out of 2) habe ich in den Logs der alten Installation gesehen (etwa Nov 07). Ist demnach fällig. Auch habe ich die Sata Kabel des neuen Servers verwendet und nur einmal zurechtgebogen (nicht komplett geknickt). Lothar Am 17.06.2017 um 13:14 schrieb Manfred Kreisl:
Am 17.06.2017 um 12:50 schrieb Lothar Behrens:
Ich sehe nun, was das Problem ist. Der Cache macht probleme. Das könnte ein RMA sein :-) Das kann aber auch durch ein SATA Kabelproblem verursacht werden.
"End-to-End error S.M.A.R.T. parameter is a part of HP's SMART IV technology and it means that after transferring through the cache RAM data buffer, the parity data between the host and the hard drive did not match. For detailed information see "
Aber auch hier gilt, nichts genaues weiß man nicht, wie so oft bei den Smart Werten
Gruß Manfred -- 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
Am 17.06.2017 um 13:51 schrieb Lothar Behrens:
@Manfred: Sorry :-)
Die Platte habe ich aus meinem alten Server in eine komplett neue HP ProLiant ML10 Kiste verbaut. Die Fehler des RAID (1 out of 2) habe ich in den Logs der alten Installation gesehen (etwa Nov 07).
Ist demnach fällig. Auch habe ich die Sata Kabel des neuen Servers verwendet und nur einmal zurechtgebogen (nicht komplett geknickt).
Smart merkt sich ja die Fehler. Es ist somit möglich und sogar wahrscheinlich, dass das Problem bereits im alten Server aufgetreten ist. Aber Fakt ist, dass die Platte jetzt 'gebrandmarkt' ist, ob das nun zu Problemen führt oder nicht, das ist ein anderes Thema Aber zurück zu deiner Frage, mit WD Platten kann man meiner Meinung nach nichts verkehrt machen ;-) Gruß Manfred
Lothar
Am 17.06.2017 um 13:14 schrieb Manfred Kreisl:
Am 17.06.2017 um 12:50 schrieb Lothar Behrens:
Ich sehe nun, was das Problem ist. Der Cache macht probleme. Das könnte ein RMA sein :-) Das kann aber auch durch ein SATA Kabelproblem verursacht werden.
"End-to-End error S.M.A.R.T. parameter is a part of HP's SMART IV technology and it means that after transferring through the cache RAM data buffer, the parity data between the host and the hard drive did not match. For detailed information see "
Aber auch hier gilt, nichts genaues weiß man nicht, wie so oft bei den Smart Werten
Gruß Manfred -- 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
-- 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
Am 17.06.2017 um 13:59 schrieb Manfred Kreisl:
Am 17.06.2017 um 13:51 schrieb Lothar Behrens:
@Manfred: Sorry :-)
Die Platte habe ich aus meinem alten Server in eine komplett neue HP ProLiant ML10 Kiste verbaut. Die Fehler des RAID (1 out of 2) habe ich in den Logs der alten Installation gesehen (etwa Nov 07).
Ist demnach fällig. Auch habe ich die Sata Kabel des neuen Servers verwendet und nur einmal zurechtgebogen (nicht komplett geknickt).
Smart merkt sich ja die Fehler. Es ist somit möglich und sogar wahrscheinlich, dass das Problem bereits im alten Server aufgetreten ist. Aber Fakt ist, dass die Platte jetzt 'gebrandmarkt' ist, ob das nun zu Problemen führt oder nicht, das ist ein anderes Thema
Aber zurück zu deiner Frage, mit WD Platten kann man meiner Meinung nach nichts verkehrt machen ;-)
Habe mir jetzt erst mal eine neue baugleiche bestellt. Später dient diese als Backup Medium (offline). Die 24/7 Option stelle ich hinten an, ist nach meiner Auffassung (jetzt) aber besser. Das Ding läuft halt 24/7 und hat momentan 8 VM's die immer auf den Platten werkeln. Ich muss mich mehr darum kümmern, den Server auch zu monitoren. Das hätte ich früher feststellen sollen :-) Gruß Lothar
participants (3)
-
Christian Boltz
-
Lothar Behrens
-
Manfred Kreisl