Warum frieren beschädigte Festplatten das gesamte System ein?

Warum blockiert eine Festplatte, von der bekannt ist, dass sie fehlerhafte Blöcke enthält (überprüft in HDTune und HDDScan), mein gesamtes System?

Es ist nicht das OS-Laufwerk; Es ist an einen anderen SATA-Port angeschlossen, und ich versuche, Dateien von diesem auf ein anderes fehlerfreies Laufwerk zu kopieren.

Ich habe dieses Problem mit fast jeder beschädigten Festplatte und jedem Windows-PC erlebt.

Ich würde erwarten, dass nur für das Programm, mit dem ich die Dateien kopiere (Windows Explorer usw.), ein Einfrieren auftritt. Stattdessen tritt auf meinem gesamten PC ein Ruckeln auf, und ich kann beim Kopieren von Dateien vom beschädigten Laufwerk weder im Internet surfen noch Filme ansehen.

Die lange Geschichte.

Ich lebe in einer ländlichen Gegend, in der es Probleme mit der Stromversorgung gibt (Stromausfälle usw.). Ich selbst benutze eine USV und meine eigenen Festplatten sind vollkommen in Ordnung. Aber meine Nachbarn bitten oft um Hilfe bei ihren PC-Problemen, und ich stelle oft fest, dass ihre Festplatten beschädigt sind, höchstwahrscheinlich aufgrund von Stromproblemen. Natürlich empfehle ich meinen Nachbarn, nach dem Austausch des beschädigten Laufwerks eine USV zu kaufen.

Ich habe mich immer gefragt, warum mein PC beim Abrufen von Daten von beschädigten Laufwerken vollständig einfriert. Handelt es sich um ein Hardwareproblem? Liegt es an der Art und Weise, wie das Betriebssystem Daten liest? Ist es etwas Windows-spezifisches und ich werde es auf * nix nicht erleben?

Wie auch immer, ich werde von nun an eine spezielle Software (wie Roadkils Unstoppable Copier) anstelle von Windows Explorer verwenden, obwohl ich nicht sicher bin, ob dies anders funktioniert, ohne den gesamten PC einzufrieren.

_{Es ist keine Bitte um Hilfe, es ist eher für Bildungszwecke, also weiß ich, warum die Dinge so funktionieren.}

Dies ist einer der Bereiche, in denen SATA nicht optimal ist. Das Problem liegt auf der Ebene des Verbindungsprotokolls für Speichergeräte vor und hängt daher nicht mit der von Ihnen ausgeführten Software zusammen. Die Verwendung eines anderen Dateikopierers oder eines anderen Betriebssystems wird die Dinge nicht auf magische Weise verbessern, außer dass möglicherweise versucht wird , andere Zeitlimitwerte festzulegen, um die Auswirkungen des Problems zu verringern (was je nach Hardware und Firmware möglich oder nicht möglich ist; siehe unten) ).

Hier gibt es einige wichtige Punkte:

1. Wenn das Laufwerk bei SATA nicht mehr reagiert, kann dies das gesamte Speichersystem binden, nicht nur das eine Laufwerk, bei dem Probleme auftreten. Es hat sicherlich das Potenzial, den gesamten Controller zu binden, und da die meisten Consumer-Systeme nur einen einzigen Festplatten-Controller (den auf der Hauptplatine integrierten) haben, bedeutet dies den gesamten Speicher. Es ist sogar noch schlimmer, wenn das Laufwerk auf eine nicht standardmäßige und / oder unerwartete Weise ausfällt, was sicherlich passieren kann, wenn das Laufwerk geringfügig ist. Sie könnten interessiert sein an Wie kann eine einzelne Festplatte in einem Hardware-SATA-RAID-10-Array das gesamte Array zum Stillstand bringen? bei Serverfehler.
2. Die meisten Consumer-SATA-Laufwerke haben lange Standard-Timeout-Perioden (in der Größenordnung von Minuten) und viele Consumer-SATA-Laufwerke haben keine konfigurierbare Fehlerbehebungssteuerung . Sogenannte "NAS" -Laufwerke verfügen häufig über konfigurierbare ERC, und High-End-Laufwerke tun dies praktisch immer. Solche Laufwerke haben möglicherweise auch kürzere Standard-Timeouts (7 Sekunden sind ein üblicher Wert). Lange Timeout-Zeiten sind vorteilhaft, wenn das Laufwerk die einzige Kopie der Daten enthält, was auf Consumer-Systemen leider häufig vorkommt. Sie sind ein Nachteil in einer redundanten Konfiguration oder wenn Sie einfach so viel wie möglich vom Laufwerk entfernen möchten, bevor es sich weiter verschlechtert.
3. Ein Laufwerk versucht so lange, einen fehlerhaften Sektor zu lesen, bis die Zeitüberschreitungsschwelle erreicht ist oder der Host einen Abbruch signalisiert. Da der SATA-Bus durch das Warten auf den Abschluss des Lesevorgangs überlastet werden kann, kann das Betriebssystem möglicherweise keinen Befehlsabbruch auf Speicherebene signalisieren, und in extremen Fällen reagieren die Laufwerke möglicherweise nicht einmal gut auf ein Zurücksetzen des SATA-Busses in solch einer Situation.

Punkt 1 ist eines der Hauptverkaufsargumente für SAS auf Servern. SAS hat eine wesentlich bessere Fehlerbehandlung als SATA. Punkt 2 ist eine Einschränkung der Laufwerksfirmware, und Punkt 3 wird wirklich nur aufgrund von Punkt 2 zum Problem.

Was also passiert, ist, dass das Betriebssystem einen "Sektoren lesen" -Befehl an die Festplatte ausgibt und die bestimmten Sektoren irgendwie beschädigt sind. Auf diese Weise wechselt die Festplatte in den Wiederholungsmodus, um zu versuchen, die Daten von den Platten zu entfernen, und versucht immer wieder, sie zu lesen, bis die Daten so gut sind, dass die eigene Fehlerkorrektur ( FEC ) der Festplatte die verbleibenden Fehler beheben kann. Wenn Sie Pech haben, ist dies möglicherweise nie der Fall, aber das Laufwerk versucht es noch einige Zeit, bevor es entscheidet, dass dieser Lesevorgang nicht erfolgreich sein wird.

Da das Betriebssystem auf den Lesevorgang wartet, verlangsamt dies zumindest den Kopiervorgang bis zum Durchforsten, und abhängig von der genauen Betriebssystemarchitektur kann das Betriebssystem für die Dauer ruckeln oder sogar einfrieren. Die Festplatte ist zu diesem Zeitpunkt mit dem ursprünglichen Lesen beschäftigt und antwortet erst auf weitere Lesebefehle, wenn die derzeit ausgeführte beendet ist (erfolgreich oder erfolglos), und andere Software kann im Allgemeinen keine bessere Leistung erbringen als das Betriebssystem läuft weiter.

Daher muss alles, was an anderer Stelle einen Lesevorgang auslöst (im Idealfall nur auf dem beschädigten Laufwerk), in der Warteschlange warten, bis das beschädigte Laufwerk den betreffenden Sektor erfolgreich liest oder feststellt, dass er nicht gelesen werden kann. Da SATA nicht optimal mit nicht reagierenden Laufwerken umgeht, kann dies dazu führen, dass nicht nur das Laufwerk, von dem Sie kopieren, seine E / A verzögert. Dies kann sehr leicht dazu führen, dass andere Software langsam wird oder auch nicht mehr reagiert, da diese Software auf die Beendigung einer anderen E / A-Anforderung wartet, selbst wenn das Betriebssystem dies bewältigen kann.

Beachten Sie hierbei auch, dass Festplatten-E / A-Vorgänge auftreten können, obwohl Sie nicht explizit auf Dateien auf der Festplatte zugreifen. Die beiden Hauptursachen hierfür sind ausführbarer Code zum Laden auf Abruf und Swap. Da Swap manchmal auch dann verwendet wird, wenn das System nicht unter Speicherdruck steht und ausführbarer Code auf Abruf auf modernen Systemen und bei modernen ausführbaren Dateiformaten üblich ist, ist eine unbeabsichtigte Aktivität beim Lesen von Datenträgern während der normalen Verwendung eine sehr reale Möglichkeit.

Wie in einem Kommentar zu der Frage von Matteo Italia ausgeführt , besteht eine mildernde Strategie darin, eine andere Speicherverbindung zu verwenden. Dies ist eine komplizierte Art zu sagen, die Festplatte in ein USB-Gehäuse zu stecken. Durch die Zusammenfassung über das USB-Massenspeicherprotokoll wird der problematische SATA-Teil vom Rest Ihres Systems isoliert. Dies bedeutet, dass theoretisch nur die E / A auf dieser bestimmten Festplatte von E / A-Problemen auf dieser Festplatte betroffen sein sollten.

Abgesehen davon wird SATA (insbesondere SATA ohne ERC auf Laufwerksebene) häufig von RAID abgeraten (insbesondere RAID-Ebenen mit Redundanz, die unter den Standardstufen alle außer RAID 0 sind ). Die langen Timeout-Zeiten und die schlechte Fehlerbehandlung können leicht dazu führen, dass ein ganzes Gerät für einen einzelnen fehlerhaften Sektor aus dem Array geworfen wird, was der RAID-Controller problemlos verarbeiten kann, wenn Redundanz vorhanden ist und der Speichercontroller einfach weiß, dass dies das Problem ist. SAS wurde für große Speicher-Arrays entwickelt, und daher mit der Erwartung, dass es gelegentlich Probleme auf verschiedenen Laufwerken geben wird, was dazu führte, dass der Fall eines einzelnen problematischen Laufwerks oder einer E / A-Anforderung ordnungsgemäß behandelt wurdeauch wenn das Laufwerk nicht. Problematische Festplatten sind in Konsumentensystemen nicht sehr verbreitet, nur weil auf diesen in der Regel nicht viele Festplatten installiert sind und auf den praktisch nie installierten Festplatten Redundanzen auftreten. Da SATA PATA / IDE und nicht SCSI ersetzen sollte (letzteres ist die angestrebte Nische von SAS), wurden wahrscheinlich die Fehlerbehandlungsfunktionen und -anforderungen (oder -garantien) für den beabsichtigten Anwendungsfall als angemessen erachtet.

Wie bereits erwähnt, ist das Problem mit Systemabstürzen aufgrund einer fehlerhaften Festplatte in erster Linie auf lange Versuche der Festplatte zurückzuführen, unlesbare Daten aus fehlerhaften Sektoren wiederherzustellen. Eines der Verkaufsargumente von Enterprise-Laufwerken ist das sehr kurze Auslesezeitlimit für ausgefallene Sektoren. Die Verwendung eines Enterprise-Laufwerks kann Ihre Probleme in gewissem Maße lindern, sie jedoch nicht lösen.

Die beste Lösung für die Zukunft ist es, ordnungsgemäße Backups zu erstellen, damit keine Wiederherstellung erforderlich ist. Das Ändern der Wiederherstellungssoftware macht keinen Unterschied, da es sich um ein Problem mit dem Firmware-Timeout handelt.

Warum frieren beschädigte Festplatten das gesamte System ein?

Sie müssen (im Allgemeinen) nicht. Es hängt wirklich vom jeweiligen Dateisystem ab, wie mit einem Festplattenfehler umgegangen wird.

Betrachten Sie ZFS, das von Grund auf für eine gewisse Fehlertoleranz ausgelegt ist. Hier ist ein Demo-Video (und eines mit weiteren Erklärungen ), in dem sie Laufwerke auf einen Amboss legen, mit einem Vorschlaghammer eine Schaukel nehmen und ein anderes Laufwerk bohren. Währenddessen läuft ZFS weiter.

Ich denke, das Problem, auf das Sie stoßen, ist, dass ein Teil des Betriebssystems auf niedriger Ebene mehrmals versucht, fehlerhafte Blöcke zu lesen, bevor er aufgibt. Diese Routine wird auf einer niedrigen Ebene implementiert, falls sie während des Bootens oder eines anderen Standalone-Betriebs benötigt wird, und daher ist es schwierig, sie wieder einzuschalten. Das Betriebssystem wird während des normalen Betriebs ständig paginieren, und es ist schwierig, konkurrierenden Anforderungen eine Priorität zuzuweisen, da das System auf niedriger Ebene die Priorität des Prozesses, der eine Paging-Anforderung besitzt, nicht kennt.