Miserable Performance und hohe CPU last beim kopieren? QSM?
Verfasst: 20. Jan 2011, 00:04
Moin!
Zur abwechslung mal ein Erfolgsbericht und ein Lösungsvorschlag für alle, die sich mit dem Problem im Betreff herumärgern. (EDIT: So ganz ist das Problem offenbar nicht aus der Welt, merke ich gerade, als ich den Beitrag fertig geschrieben habe --> s.u.)
Zum Hintergrund: Ich habe mein System neu aufsetzen müssen und in diesem Zuge 2 zusätzliche Samsung HD203WI installiert, die dem Serverspeicher hinzugefügt wurden. Das System ist auf einer WD 5000AACS installiert. Das Kopieren der Daten von den alten Platten, die (noch) nicht dem Serverspeicher hinzugefügt waren, auf die neuen Platten im Serverspeicher verlief zunächst performant und problemlos. Ich hatte das System auch einige Tage mit zunächst nur einer HD203WI im Betrieb, da mir ein Kabel fehlte. Am vergangenen Wochenende habe ich das SATA kabel bekommen, die zweite HD203WI dem Serverspeicher hinzugefügt und die restlichen Daten von der Samsung HD154UI auf den Serverspeicher zu kopieren. Einen Tag später logge ich mich am Server ein und bemerke, dass der Kopiervorgang ins Stocken geraten ist und sich das System nahezu aufgehängt hat. Ich habe den Vorgang abgebrochen und neu gestartet. Nach dem Hochfahren habe ich multiple Herzattacken bekommen. Die Integrität war nicht mehr gewährleistet (Dateizugrff nicht möglich, da Datenträger nicht verfügbar oder so ähnlich), und eine HD203WI wurde im Speichermanager als Fehlerhaft angezeigt und ließ sich nicht reparieren. Dies war aber leider die erste Platte, die ich dem Serverspeicher hinzugefügt hatte und sie umfasste ca. 90% meiner Daten. Eine alte Platte, von der ich die kopierten Daten bereits gelöscht hatte konnte ich mit Parted Magic erstaunlich einfach wieder rekonstruieren, dass brachte Erleichterung...
Dann habe ich mich der HD203WI, die so einfach nicht repariert werden konnte, angenommen ud mit Testdisk untersucht. Die MFT (Master File Table) sowie die Spiegelung haben sich als defekt herausgestellt und konnten nicht repariert werden (auch nicht mit GetBackData NTFS, was ansonsten ein guter Tip ist). Also das Ding abgeklemmt, dann im Speichermanager entfernt, der mir mitgeteilt hat, dass ich alle Daten verlieren würde - hilft ja nichts, habe ich mir gedacht und bestätigt. Anschließend die Festplatte formatieren wollen (normal, nicht schnell) und feststellen müssen, dass der Vorgang bei 55% anhält. Ein bisschen recherchiert und herausgefunden, dass dies ggf. Probleme der Formatierung unter Windows (XP, WHS) mit Platten der 2TB Generation zuruckzuführen ist. Ein anderer User hatte genau das gleiche Problem mit 2 Platten am WHS. Naja, beim ausführlichen Checkdisk Test (erinnere mich nicht an die 3 Parameter) wurde die Prüfung bei 64% immer langsamer und langsamer. Habe ich auch abgebrochen, da ich ca. 3 Tage darauf hätte warten müssen. Also habe ich die Platte dann, mangels geeigneter Möglichkeiten der Kontrolle schnell formatiert und wieder dem Speicher hinzugefügt.
Ich habe dann die Kopieraktion von neuem begonnen und mich gewundert, wie langsam dies nun erfolgte. Max 1 mb/s!!! Also abgebrochen und auf Problemsuche. Festgestellt, dass sowohl beim primären als auch beim sekundären IDE controller (ja, SATA läuft bei mir im nativen IDE Modus) ein Gerät auf PIO Modus stand. Windows handelt es wohl so, das wenn CRC timeouts passieren oder schreib- bzw- Lesefehler gehäuft aftreten die Geräte von UDMA6 immer weiter runtergestuft werden bis auf PIO. Und genau das ist bei mir passiert. Folgender Threat, bei dem ein Registry Eingriff beschrieben wird, der die automatische Windows Einstufung zurücksetzt, hat mir weitergeholfen:
http://www.derfisch.de/smf2/index.php?topic=3157.0
ALso, wenn Ihr auch Probleme mit der Schreib- oder Leseperformance habt, kontrolliert mal im Gerätemanager die Controllereigenschaften!
Sh**: Merke gerade, dass die der Kopiervorgang sich wieder aufgehängt hat. Woran liegt das blos? Eine eine Idee?
Beste Grüße,
boxbooster
Zur abwechslung mal ein Erfolgsbericht und ein Lösungsvorschlag für alle, die sich mit dem Problem im Betreff herumärgern. (EDIT: So ganz ist das Problem offenbar nicht aus der Welt, merke ich gerade, als ich den Beitrag fertig geschrieben habe --> s.u.)
Zum Hintergrund: Ich habe mein System neu aufsetzen müssen und in diesem Zuge 2 zusätzliche Samsung HD203WI installiert, die dem Serverspeicher hinzugefügt wurden. Das System ist auf einer WD 5000AACS installiert. Das Kopieren der Daten von den alten Platten, die (noch) nicht dem Serverspeicher hinzugefügt waren, auf die neuen Platten im Serverspeicher verlief zunächst performant und problemlos. Ich hatte das System auch einige Tage mit zunächst nur einer HD203WI im Betrieb, da mir ein Kabel fehlte. Am vergangenen Wochenende habe ich das SATA kabel bekommen, die zweite HD203WI dem Serverspeicher hinzugefügt und die restlichen Daten von der Samsung HD154UI auf den Serverspeicher zu kopieren. Einen Tag später logge ich mich am Server ein und bemerke, dass der Kopiervorgang ins Stocken geraten ist und sich das System nahezu aufgehängt hat. Ich habe den Vorgang abgebrochen und neu gestartet. Nach dem Hochfahren habe ich multiple Herzattacken bekommen. Die Integrität war nicht mehr gewährleistet (Dateizugrff nicht möglich, da Datenträger nicht verfügbar oder so ähnlich), und eine HD203WI wurde im Speichermanager als Fehlerhaft angezeigt und ließ sich nicht reparieren. Dies war aber leider die erste Platte, die ich dem Serverspeicher hinzugefügt hatte und sie umfasste ca. 90% meiner Daten. Eine alte Platte, von der ich die kopierten Daten bereits gelöscht hatte konnte ich mit Parted Magic erstaunlich einfach wieder rekonstruieren, dass brachte Erleichterung...
Dann habe ich mich der HD203WI, die so einfach nicht repariert werden konnte, angenommen ud mit Testdisk untersucht. Die MFT (Master File Table) sowie die Spiegelung haben sich als defekt herausgestellt und konnten nicht repariert werden (auch nicht mit GetBackData NTFS, was ansonsten ein guter Tip ist). Also das Ding abgeklemmt, dann im Speichermanager entfernt, der mir mitgeteilt hat, dass ich alle Daten verlieren würde - hilft ja nichts, habe ich mir gedacht und bestätigt. Anschließend die Festplatte formatieren wollen (normal, nicht schnell) und feststellen müssen, dass der Vorgang bei 55% anhält. Ein bisschen recherchiert und herausgefunden, dass dies ggf. Probleme der Formatierung unter Windows (XP, WHS) mit Platten der 2TB Generation zuruckzuführen ist. Ein anderer User hatte genau das gleiche Problem mit 2 Platten am WHS. Naja, beim ausführlichen Checkdisk Test (erinnere mich nicht an die 3 Parameter) wurde die Prüfung bei 64% immer langsamer und langsamer. Habe ich auch abgebrochen, da ich ca. 3 Tage darauf hätte warten müssen. Also habe ich die Platte dann, mangels geeigneter Möglichkeiten der Kontrolle schnell formatiert und wieder dem Speicher hinzugefügt.
Ich habe dann die Kopieraktion von neuem begonnen und mich gewundert, wie langsam dies nun erfolgte. Max 1 mb/s!!! Also abgebrochen und auf Problemsuche. Festgestellt, dass sowohl beim primären als auch beim sekundären IDE controller (ja, SATA läuft bei mir im nativen IDE Modus) ein Gerät auf PIO Modus stand. Windows handelt es wohl so, das wenn CRC timeouts passieren oder schreib- bzw- Lesefehler gehäuft aftreten die Geräte von UDMA6 immer weiter runtergestuft werden bis auf PIO. Und genau das ist bei mir passiert. Folgender Threat, bei dem ein Registry Eingriff beschrieben wird, der die automatische Windows Einstufung zurücksetzt, hat mir weitergeholfen:
http://www.derfisch.de/smf2/index.php?topic=3157.0
ALso, wenn Ihr auch Probleme mit der Schreib- oder Leseperformance habt, kontrolliert mal im Gerätemanager die Controllereigenschaften!
Sh**: Merke gerade, dass die der Kopiervorgang sich wieder aufgehängt hat. Woran liegt das blos? Eine eine Idee?
Beste Grüße,
boxbooster