Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Stimmt auch wieder, wäre etwas schlecht, wenns meine Backup-Platte erwischt hätte; die läuft aber schon seit Langem ohne Probs.
Is bis jetzt die erste von WD die Zicken macht; nur halt etwas schade, weil ich sie bis jetzt noch fast garnicht benutz hab.
Dann werd ich mich mal ran machen und doch etwas gründlicher suchen.
Hehe^^, da fällt mir gerade ein, ich hab noch eine IDE Platten von Samsung im Keller, die kann ich dann morgen auch gleich mal "rumbasteln". Diese wird unter Windows nicht mehr erkannt. Im Installationssetup von XP und unter Knoppix komm ich aber noch dran; braucht aber eine halbe Ewigkeit bis das Setup zum Festplattenauswahl wechselt bzw. Knoppix die Platte "untesucht" hat und dann startet. Hab sie dann auch gleich mal formatiert, half aber leider nich.
Das ganze funktioniert aber nur, solange die Platte per (e)SATA angeschlossen ist! Die allermeisten USB-Controller unterdrücken die S.M.A.R.T.-Befehle, damit ist die automatische Reparatur deaktiviert.
Was hat das mit der Schnittstelle zu tun? So weit ich weiß funktioniert das alles festplattenintern und muss nicht durch externe Befehle in Gang gebracht werden. Was manche USB-Bridge-Chips unterdrücken, sind das Auslesen der Smart-Logs und eventuelle das manuelle in Gang bringen der "Self-tests" (was du wahrscheinlich meinst). Aber vielleicht weißt du darüber mehr als ich.
_TK_ schrieb:
Die 244 zur Auslagerung vorgemerkten (pending - schwebend) werden beim Formatieren / Nullen (mit aktivem S.M.A.R.T. - also nicht über USB) auf jeden Fall ausgelagert, und sollten dann bei "reallocated" erscheinen.
Das ist nicht gesagt. Sollte der Schreibzugriff erfolgreich gewesen sein, wird der unter Current Pending geführte Sektor als nicht mehr defekt angesehen und nicht ausgetauscht. So kommt es nach einer Nullung oder einer Formatierung vor, dass der Zähler von "Current Pending Sectors" wieder auf 0, bei "Reallocated Sector Count" aber nicht angestiegen ist. Jedenfalls wird nicht "auf jeden Fall" ausgelagert.
/Edit
_TK_ schrieb:
- current pending: Daten können dank Fehlerkorrektur noch(!) korrekt ausgelesen werden. Beim nächsten Schreibvorgang wird geprüft, ob wieder die Fehlerkorrektur eingreifen muß, oder nur schlecht geschrieben wurde, z.B. bei oxidierten Kontakten auf der Leiterplatte. Falls wieder schlecht lesbar, wird der Sektor gegen einen Reservesektor ausgetauscht (reallocated sector).
Laut der FAQ des Smartmontools-Projekts sind das Sektoren, die nicht gelesen werden konnten aber noch Daten enthalten und deshalb noch nicht ausgetauscht wurden. Erst wenn die Daten bei erneutem Lesezugriffen dennoch gerettet werden konnten oder ein Schreibzugriff erfolgt ist, wird der Sektor entweder ausgetauscht oder, bei erfolgreichem Schreibzugriff, als gesund angesehen, wodurch der Eintrag unter "Current Pending Sector" ebenfalls verschwindet. Weißt du mehr bzw. genaueres?
SMART - selbständige Auslagerung von defekten Sektoren:
Ich würde es mir wünschen, daß das unabhängig funktioniert. Sinnvoll wäre es ja! Aber leider erlebe ich es sehr oft, daß Festplatten, gerade aus externen Gehäusen, etliche defekte Sektoren haben. Manchmal stehen die wenigstens bei "pending" in der Liste, aber oftmals ist da überall "0" zu sehen. Sobald ich diese Platten dann zum Auslesen anschließe, steigen die entsprechenden Zähler.
Außerdem kann ich bei meiner (Spezial-) Technik die automatische Sektor-Auslagerung explizit unterbinden, was beim Auslesen von Platten mit defekten Köpfen sehr sinnvoll ist. Also ist es über Befehle steuerbar.
Ich kann es mir nur so erklären, daß SMART explizit durch BIOS oder Betriebssystem aktiviert werden muß, um wirksam sein zu können. Natürlich protokolliert die Platte intern alles, aber sie wird nicht von sich aus mit der Reparatur aktiv. Vermutlich aus Rücksicht auf RAID-Systeme, bei denen sonst das RAID-controllerinter Defektmanagement aus dem Tritt kommen könnte. Ich habe auch überhaupt kein Verständnis dafür, daß Gigabyte bis heute im BIOS standardmäßig (auch nach Batteriewechsel) SMART deaktiviert hat.
Ja, manchmal schrumpt auch die Anzahl der schwebenden (pending) Sektoren. Ich habe das einmal erlebt, als ich bei einer Platte die stark korrodierten Kontakte auf der Platine geputzt hatte. Dank des Glasfaserpinsels setzte eine Spontanheilung ein. Das findet man aber nur sehr selten, in den allermeisten Fällen sind die Sektoren einfach nur schwach, d.h. die Beschichtung der Scheiben mangelhaft.
Current Pendings können auch durch abgebrochene Schreibzugriffe (durch z.B. Stromausfall, instabile Stromversorgung oder unsanftes Ausschalten verursacht) entstehen. Diese Sektoren sind dann nicht wirklich defekt sondern es stimmt nur der Fehlerkorrekturcode und der Dateninhalt des Sektors nicht mehr überein. Der nächste Schreibzugriff korrigiert das, wodurch die "Current Pinding"-Liste schrumpft. Das ist meines Erachtens wiederum nicht so selten.
Wenn deine Vermutung mit der Rücksicht auf RAID-Systeme stimmt, dann frage ich mich, für was es spezielle RAID-Editions gibt. Die wären dann ja überflüssig.
_TK_ schrieb:
Aber leider erlebe ich es sehr oft, daß Festplatten, gerade aus externen Gehäusen, etliche defekte Sektoren haben. Manchmal stehen die wenigstens bei "pending" in der Liste, aber oftmals ist da überall "0" zu sehen. Sobald ich diese Platten dann zum Auslesen anschließe, steigen die entsprechenden Zähler.
"Current Pending Sectors"...
Laut der FAQ des Smartmontools-Projekts sind das Sektoren, die nicht gelesen werden konnten aber noch Daten enthalten und deshalb noch nicht ausgetauscht wurden. Erst wenn die Daten bei erneutem Lesezugriffen dennoch gerettet werden konnten oder ein Schreibzugriff erfolgt ist, wird der Sektor entweder ausgetauscht oder, bei erfolgreichem Schreibzugriff, als gesund angesehen, wodurch der Eintrag unter "Current Pending Sector" ebenfalls verschwindet. Weißt du mehr bzw. genaueres?
Nee, leider nicht. Ich sehe es nur in der Praxis, wie es funktioniert. Wenn ich Entwickler wäre, hätte ich es so umgesetzt, wie oben beschrieben.
Es gibt nur Sektoren, die fehlerfrei ausgelesen werden können, und solche, wo die Fehlerkorrektur (CRC im Jargon) arbeiten muß, d.h. wo aus den im Offset jedes Sektors gespeicherten Korrekturdaten ein gekipptes Bit wieder herausgerechnet werden kann. Nicht zu verwechseln mit der sowieso ständig aktiven Fehlerkorrektur, die z.B. bei Seagate so schön die RAW-Fehlerliste füllt.
Die mit einem gekipptem Bit werden bei "pending" vorgemerkt, die mit 2 oder mehr, also nicht mehr korrigierbarem Inhalt bei "offline uncorrectable".
Die nächste Platte mit defekten Sektoren werde ich in einem USB-Gehäuse stressen und penibel untersuchen, versprochen. Aber es waren wirklich viele externe Platten dabei, die lt. Stundenzähler fast ununterbrochen liefen. Dort war der offline-check (meist aller 4 Stunden) ganz offensichtlich nicht aktiv.
Ergänzung ()
Bei den RAID-Editions sind die Platten hoffentlich besser getestet als die normale Massenware, außerdem (und vor allem, wie mir ein Mitarbeiter einer Festplattenfirma erzählte) sind die Timeouts wesentlich enger gesetzt. Eine Desktopplatte darf sich durchaus einige Sekunden mit der Fehlerkorrektur aufhalten, bei RAID-Platten ist dafür der Controller zuständig. Ebenso bei Videoplatten, wo ein fehlerhaftes Byte weitaus weniger schwer wiegt als 5 Sekunden Datenausfall.
außerdem (und vor allem, wie mir ein Mitarbeiter einer Festplattenfirma im Vertrauen erzählte) sind die Timeouts wesentlich enger gesetzt. Eine Desktopplatte darf sich durchaus einige Sekunden mit der Fehlerkorrektur aufhalten, bei RAID-Platten ist dafür der Controller zuständig.
Ich muss mal wirklich sagen, das war ein wirkliches Vergnügen solch eine Diskussion zu ... lesen.
Wenn ihr nichts dagegen habt, würde ich mich freuen, auch von dem Ergebnis des Tests zu erfahren.
P.S.
Hab mir die Testversion von Safe Erase runtergeladen und lösche die Platte gerdade, damit ich sie morgen untauschen/in Reparatur geben kann.
Es gibt nur Sektoren, die fehlerfrei ausgelesen werden können, und solche, wo die Fehlerkorrektur (CRC im Jargon) arbeiten muß, d.h. wo aus den im Offset jedes Sektors gespeicherten Korrekturdaten ein gekipptes Bit wieder herausgerechnet werden kann. Nicht zu verwechseln mit der sowieso ständig aktiven Fehlerkorrektur, die z.B. bei Seagate so schön die RAW-Fehlerliste füllt.
Die mit einem gekipptem Bit werden bei "pending" vorgemerkt, die mit 2 oder mehr, also nicht mehr korrigierbarem Inhalt bei "offline uncorrectable".
Dagegen spricht allerdings, dass unter "Current Pending" geführte Sektoren bei einem Oberflächentest (z.B. der von HD-Tune) gefunden und als defekt (rote Kästchen bei HD-Tune) angezeigt werden. Auch Checkdisk zeigt, wenn ich mich jetzt nicht gewaltig irre, solche Sektoren als defekt an. Nach einem gezielten Schreibzugriff oder einer Nullung der gesamten Platte ist die "Current Pending"-Liste dann leer und "rote Kästchen" nach einem erneuten Scan nicht mehr vorhanden.
Smartmontools FAQ schrieb:
Normally when an uncorrectable sector is found, the disk puts this onto a 'pending sector list' to indicate that it should be replaced with a spare good sector. However this replacement won't take place until either the disk can read the data on the bad sector, or is commanded to write new data to that bad sector.
Es ist leider so, dass bei vielen der zahlreichen Toolbeschreibungen nur unzureichende, falsche oder gar keine Erklärung für einige der SMART-Daten gegeben werden.
Von der Quelle, nämlich den HDD-Herstellern, deren Firmware diese Daten ja erfasst, ist dagegen bei einigen so gut wie nichts in Erfahrung zu bringen.
Die "Pending Sector List" wird bei auftretetenden Lesefehlern erstellt.
Wenn sich die Platte langweilt und im Selbsttestverfahren trotz Inaktivität lustig vor sich hinklackert, und dabei von selbst defekte Sektoren findet, die vom Benutzer nicht angesteuert wurden, werden die im "Offline Uncorrectable Count" vermerkt.
Die interne ECC-Korrektur der Daten hat damit überhaupt nichts zu tun, und schon gar nicht die CRC-Checks, die bei der Übertragung von/zum Controller über das ATA-Interface auftreten.
Erst wenn der Versuch fehlschlägt, per ECC die Daten richtigzustellen, liegt offiziell ein Lesefehler vor.
Im HDTune Error Scan wird dann dieser Sektor rot markiert, weil in diesem Test die interne Recovery abgeschaltet wird, welche im Normalfall noch einige Male einen erneuten Versuch startet, den defekten Sektor doch noch richtig zu lesen, was in den meisten Fällen auch nach einiger Zeit gelingt - wenn äußere Einflüsse wie z.B. Vibratíonen o.ä. für den Fehler verantwortlich gewesen sind.
Woher hast du das? Manchmal wird HD-Tune an bestimmten Stellen merklich langsamer, weil Lesefehler aufgetreten sind oder defekte Sektoren gefunden wurden. Das deutet allerdings auf eine arbeitende interne Fehlerkorrektur hin.
Das Problem ist ja auch, dass neben den fehlenden allgemeinen Angaben zum Defekt Management von Festplatte, im Grunde jeder Hersteller sein eigenes Süppchen kocht und das Defekt Management von Hersteller zu Hersteller anders arbeiten kann. Wie Festplatten intern arbeiten ist nämlich nicht genormt.
Da ich zum Auslesen von defekten Platten kein Windows verwende, lege ich mich hier lieber nicht fest. Mit dd_rescue oder schwerer Technik geht das viel sauberer.
Fakt ist aber, daß man "schwebende" Sektoren fast immer fehlerfrei auslesen kann. Während die Festplatte rumpelt, kann man mit "smartctl -a /dev/sd<x>" das Treiben schön beobachten.
Chkdsk arbeitet auf Dateisystemebene, nicht auf Hardwareniveau! Chkdsk markiert also schlechte Sektoren in einer dateisysteminternen Liste, wie schon seit tiefsten DOS-Zeiten. Damit ist es auch für nicht-SMART-Laufwerke geeignet. Durch gezieltes Neuschreiben / Nullen der kompletten Platte werden alle als schwach erkannten Sektoren ausgelagert, damit ist wieder ein definierter Zustand hergestellt, Schön mit HDTUNE zu beobachten. Ich nehm' dazu "dd_rescue /dev/sd<x> /dev/sd<x>", d.g. komplette Platte auslesen und neu schreiben. Im Nachbarfenster wird smartctl -a ... aufgerufen, bzw. ganz bequem über Webmin (bin mit Rechnern großgeworden, die bestenfalls Klötzchengrafik, und noch keine Maus hatten).
Madnex schrieb:
Demnach ist ein Pending Sector bereits ein nicht mehr lesbarer Sektor.
...Ist wirklich interessant, was da steht. Ich hoffe nur mal, dass sie auch Ahnung haben wovon sie schreiben.
Einer hat Recht, einer liegt daneben...
Wie bei der Diskussion über die globale Erwärmung. Über das pseudowissenschaftliche Geschwätz von wegen CO2 als Treibhausgas kann man sich trefflich streiten, aber das Ziel der Debatte - Energie sparen, und Wälder aufforsten - ist gut und richtig.
Hauptsache, das Defektmanagement kann Datenverlust erfolgreich vermeiden. Und ich ziehe mich jetzt entspannt ins Wochenende zurück
Wie oft eine HDD von selbst versucht, den Fehler durch mehrmaliges Lesen zu korrigieren, ist herstellerspezifisch und ist von geringer Anzahl. Dann wird einfach das Zeug übertragen und bei physischen I/Os in den I/O-Statusbits vermerkt, dass ein Fehler aufgetreten ist und die Daten inkorrekt sind. Das führt bei HDTune zur Rotfärbung.
Ein normalerweise vom Programm abgesetzter I/O wird aber auf Systemebene im Fehlerfall noch bis zu 128x wiederholt, danach bei Fehlschlag ein Eintrag im Eventlog erstellt.
@Ernst@at
Du hast doch geschrieben, dass die interne Recovery während des Oberflächentests abgeschaltet wird. Das widerspricht aber deinem letzten Beitrag. Oder, was genau meinst du mit "interne Recovery abgeschaltet"?
_TK_ schrieb:
Fakt ist aber, daß man "schwebende" Sektoren fast immer fehlerfrei auslesen kann. Während die Festplatte rumpelt, kann man mit "smartctl -a /dev/sd<x>" das Treiben schön beobachten.
HDTune setzt seine I/Os auf physischer Ebene ab, während im Normalfall sonst jeder Zugriff über das Filesystem abgehandelt wird und daher auch dessen interne Recovery abläuft. Das war damit gemeint - ich entschuldige mich für die unklare Ausdrucksweise es hätte korrekt "... die Filesystem-interne Recovery umgangen wird" heißen sollen.
chkdsk arbeitet hingegen auf Filesystem-Ebene, aber ohne dem "automatic retry" im Fehlerfall. Nicht lesbare Sektoren werden nicht neu beschrieben, sondern nur Clusterweise in der $Bitmap als belegt markiert, und der Datei $BadClus zugeordnet.
Daher verschwinden die "pending Sectors" dabei auch nicht, weil sie zur Auslagerung eines Schreibvorganges bedürfen.
Bei einem erfolgenden Schreibvorgang prüft die HDD jedoch intern, ob sie den Sektor auch wieder fehlerfrei lesen kann; wenn ja verschwindet der aus der pending list, wenn nein, wird ausgelagert. Damit wird verhindert, dass wegen eines fehlerbehafteten Schreibvorganges sinnlos auf Spare-Sektoren ausgelagert wird, obwohl der Sektor an sich fehlerfrei ist.
Ergänzung ()
_TK_ schrieb:
Ich nehm' dazu "dd_rescue /dev/sd<x> /dev/sd<x>", d.g. komplette Platte auslesen und neu schreiben.
Das ist die elegante Methode, um sich das Sichern einer ganzen Platte mit anschließendem write-all-zeroes zu ersparen.
Sie hat nur einen kleinen Nachteil: kann ein Sektor(auch nach hunderten Versuchen) nicht korrekt gelesen werden, so wird er auch nicht neu geschrieben und bleibt defekt.
Einige andere high-sophisticated Methoden speichern die falschen Daten(die nicht immer gleich falsch sein müssen) in einer Datenbank und können u.U. daraus den richtigen Inhalt rekonstruieren. Schlimmstenfalls hat man dann eben eine Datei, von der man dann aber weiß, dass sie nicht komplett richtig ist und auch wo diese Stelle liegt.
Mein "Kopieromat" (toll teuer, sehr leistungsfähig) arbeitet nach diesem Prinzip, d.h. auch Sektoren mit CRC-Fehler werden gelesen, protokolliert und geschrieben. Für normale Festplatten ist aber Linux immernoch das Mittel der Wahl.
