Dies ist das zweite Mal, dass dieser Fehler beim Ausführen von auftritt badblocks, ungefähr 2 Jahre nach dem letzten Mal, und die große Mehrheit der Faktoren von der Hardware (Kabel usw.) bis zur Software (die Installation des Betriebssystems selbst) hat sich seitdem geändert. Die einzigen relevanten gemeinsamen Faktoren sind Cygwinund das badblocksProgramm selbst, sodass es sehr wahrscheinlich ist, dass das Problem bei einem dieser Faktoren liegt.
Beim Ausführen badblocksim destruktiven Modus (also mit dem -wSchalter) erhalte ich den Fehler:
Seltsamer Wert (4294967295) in do_writerrors
...in jeder Phase des Schreibens der Muster auf das Laufwerk.
Soweit ich das beurteilen kann, tritt dieser Fehler anscheinend nur auf, wenn ich den Befehl mit dem angegebenen letzten Block ausführe, der wie folgt gemeldet wird fdisk -l:
$ fdisk -l /dev/sda
Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
$ badblocks -b 512 -vws /dev/sda 1953525168 1953525168
Checking for bad blocks in read-write mode
From block 1953525168 to 1953525168
Testing with pattern 0xaa: Weird value (4294967295) in do_writerrors)
done
Reading and comparing: 1953525168ne, 0:00 elapsed. (0/0/0 errors)
done
Testing with pattern 0x55: Weird value (4294967295) in do_writerrors)
done
Reading and comparing: done
Testing with pattern 0xff: Weird value (4294967295) in do_writerrors)
done
Reading and comparing: done
Testing with pattern 0x00: Weird value (4294967295) in do_writerrors)
done
Reading and comparing: done
Pass completed, 1 bad blocks found. (1/0/0 errors)
$ badblocks -b 512 -vws /dev/sda 1953525168 1950000000
Checking for bad blocks in read-write mode
From block 1950000000 to 1953525168
Testing with pattern 0xaa: Weird value (4294967295) in do_writerrors)
done
Reading and comparing: 1953525168ne, 0:49 elapsed. (0/0/0 errors)
done
Testing with pattern 0x55: Weird value (4294967295) in do_writerrors)
done
Reading and comparing: done
Testing with pattern 0xff: Weird value (4294967295) in do_writerrors)
done
Reading and comparing: done
Testing with pattern 0x00: Weird value (4294967295) in do_writerrors)
done
Reading and comparing: done
Pass completed, 1 bad blocks found. (1/0/0 errors)
Wie man sehen kann, führt dies auch zu einer falschen Meldung eines fehlerhaften Blocks, während dieser vermeintlich fehlerhafte Block über CrystalDiskInfo nirgends zu finden ist:
Zu diesem Zeitpunkt wurde das Laufwerk bereits mehrere Male auf Null gesetzt und badblocksseine letzten Blöcke wurden Dutzende Male beschrieben. Es bestand also reichlich Gelegenheit, dass die SMART-Werte einen fehlerhaften Sektor im Block erkannt haben, 1953525168falls einer vorhanden war.
Was bedeuten diese Fehler eigentlich und was könnten ihre Ursachen sein?
Antwort1
Obwohl harrymc Ihnen möglicherweise den Kern meiner Antwort gegeben hat (nämlich 4294967295als -1) unsigned int, hat er nicht näher erläutert, warum badblockses nicht einfach als „erkannt“ wird -1(also warum bei einer Cygwin-Version davon unter Windows der Fehler „seltsamer Wert“ auftritt).
badblocksIch habe mir den Code von Cygwin angesehen :
https://github.com/tytso/e2fsprogs/blob/v1.45.4/misc/badblocks.c#L463
Und ich bin auf Folgendes gestoßen:
[tom@archlinux ~]$ cat test.c
#include <stdio.h>
unsigned int eh() {
return -1;
}
int main() {
long got;
got = eh();
printf("%ld\n", got);
got = (long) eh();
printf("%ld\n", got);
got = (int) eh();
printf("%ld\n", got);
}
[tom@archlinux ~]$ cc test.c
[tom@archlinux ~]$ ./a.out
4294967295
4294967295
-1
[tom@archlinux ~]$
Im Grunde bedeutet dies, dass Sie, wenn Sie eine vorzeichenlose Variable (die absichtlich zum Speichern eines vorzeichenbehafteten Werts verwendet werden kann) als vorzeichenbehaftete Variable interpretieren möchten, diese mit ihrer eigenen Größe interpretieren sollten, nicht aber mit der Größe einer anderen Variablen, in die Sie ihren Wert einfügen möchten.
Ich bin nicht wirklich mit Programmierung vertraut, aber wie Sie sehen, ist die (_ssize_t)Typumwandlung in reent/writer.cwahrscheinlich falsch. Wenn wir annehmen, _write()dass vom intTyp (oder einem beliebigen vorzeichenbehafteten Typ) ist, ist eine solche Typumwandlung überflüssig. Wenn wir annehmen, _write()dass vom unsigned intTyp ist, dann sollte die erforderliche Typumwandlung sein (int). (Zur Information: Sie ist nur erforderlich, weil wir seinen Wert auf ein „erweitern“ _ssize_t(also ret). Ein Vergleich wie (an_unsigned_int == -1)könnte meines Wissens nach problemlos funktionieren.)
Allerdings muss ich sagen, dass dies nur eine Vermutung ist, da ich nicht wirklich weiß, wie _write()Cygwin es verwendet (z. B. ob es etwas mitDas, und wenn ja, ob die Dokumentation einfach nur Mist ist). Aber ich denke, es ist ein gültiger Fall für eineFehlerbericht, was Sie vielleicht dazu bringen könnte, mehr herauszufinden.
Aktualisieren:Daskönnte das Commit sein, das die "Regression" einführt (wie Sie sehen, _ssize_twürde es auf basieren __SIZE_TYPE__(was im Wesentlichen size_tder Commit-Nachricht entspricht). Es würde wahrscheinlich enden, unsigned longwenn Cygwin 64-Bit ist, basierend aufDasUndDas), daher wette ich, dass Sie das Problem mit 32-Bit-Cygwin nicht reproduzieren können (nicht einmal unter 64-Bit-Windows). Es könnte erwähnenswert sein, dassein noch früheres Commitwahrscheinlich einmal "behoben". Deshalb nenne ich es eine "Regression".
Update 2: und ja, ich habe recht:
Vielleicht sollte ich mir jetzt Visual Studio holen und ein bisschen nachsehen _write()(und vielleicht auch …)write()
PS: Sie sollten nicht auf den Fehler „seltsamer Wert“ stoßen, wenn Sie einen schreibgeschützten Test für „letzter Block + 1“ durchführen, da _read()zurückgegeben würde 0, im Gegensatz zu _write()was zurückgegeben -1und errnoauf gesetzt würde ENOSPC, wenn es „versucht, am Ende der Datei zu lesen" (die Fahrt).
Antwort2
Der Dezimalwert wird 4294967295in Hex FFFFFFFFeinfach -1als vorzeichenlose 32-Bit-Ganzzahl dargestellt. Dies ist ein häufiger API-Fehlercode und hat keine andere Bedeutung. Das Dienstprogramm badblocksist sehr einfach und wurde vor Jahrzehnten von Linus Torvalds geschrieben. Es schreibt nur Daten aus und liest sie wieder ein.
Nicht korrigierbare Sektorenanzahl Gibt die Anzahl der fehlerhaften Sektoren an, die die Festplattenfirmware erkannt hat, aber nicht in fehlerfreie Sektoren verschieben konnte, da diese Sektoren nicht gelesen werden konnten. Die Firmware hat den Versuch, diese Sektoren zu verschieben, aufgegeben.
Es gibt also 459 nicht erkennbare Sektoren, die die Firmware erkannt hat, aber nicht neu zuordnen kann.
Die Scheibe befindet sich zweifellos in einer Endphase.
Wenn Sie die Festplatte retten möchten und sich nicht um ihren Inhalt kümmern, können Sie versuchen, sie tief zu formatieren, um alle guten Sektoren neu zu schreiben und zu erneuern und gleichzeitig die Sektoren, die die Firmware nicht berühren kann, als fehlerhaft zu markieren. Ein Dienstprogramm des Herstellers ist hier vorzuziehen. Cygwin ist zu vermeiden, da dessen Linux-Dienstprogramme keine gute Windows-Integration garantieren.
Der DiamondMax-Supportseite schlägt das recht neue Festplatten-Dienstprogramm vor DiscWizard-Version: 23.0.17160, das möglicherweise die Tiefenformatierung durchführen kann. Dies ist ein Windows-Dienstprogramm.
Handelt es sich bei der betreffenden Festplatte um die Windows-Systemfestplatte, müssen Sie das Dienstprogramm möglicherweise von einer Windows PE-Startdiskette oder einer Rettungsdiskette wie Modifiziertes Win10PEx64 von Bob.OmbSie können auch ein Bootfähige Windows PE-basierte Wiederherstellungs-CD wie zum Beispiel Hirens BootCD PEZur Not können Sie versuchen, die Festplatte über einen Linux Live-Boot zu formatieren.
(Ergänzung zum umgeschriebenen Beitrag)
Die obige Antwort wurde vom Verfasser offenbar zwei Jahre vor dem Schreiben und dem Austausch der Festplatte akzeptiert. In diesem Teil geht es um die neue Festplatte.
Die neue Festplatte ist in einwandfreiem Zustand und weist keinerlei Mängel auf, dennoch gibt Badblocks eine Fehlermeldung aus.
Badblocks ist ein uraltes Dienstprogramm, das von Linus Torvalds geschrieben wurde, möglicherweise sogar bevor es Linux gab. Es erstellt lediglich eine temporäre Datei, schreibt in diese, bis das Ende des Speicherplatzes erreicht ist, und liest die Daten dann erneut. Als Festplattentest ist es miserabel und „testet“ nur den freien Speicherplatz auf der Festplatte.
Darüber hinaus wird es unter Cygwin und nicht unter Windows ausgeführt, sodass es äußerst zweifelhaft ist, ob es die von Windows zurückgegebenen Fehlercodes versteht. Es kann nicht einmal den echten Fehlercode melden, sondern meldet immer einen -1
Fehlercode. Man kann sich nicht vorstellen, was passieren würde, wenn Cygwin versucht, einen Windows-API-Fehlercode in den vermeintlich entsprechenden Linux-Fehlercode zu übersetzen.
Ehrlich gesagt würde ich diesen einen sporadischen Fehler als bedeutungslos ignorieren, wahrscheinlich nur weil der Rückgabecode „kein Speicherplatz mehr vorhanden“ missverstanden wurde, der entweder von Badblocks oder Cygwin missverstanden wurde. Die von der SMART-Firmware zurückgegebenen Daten sind viel aussagekräftiger.
In der Post Äquivalent zu Badblocks unter Windows oder DOS Es wurden mehrere Vorschläge gemacht, die alle viel besser sind als Badblocks, da sie die gesamte Festplatte und nicht nur den freien Speicherplatz testen.
Eine gute Alternative ist chkdsk /r, das das Windows-Dienstprogramm verwendet
chkdsk
um fehlerhafte Sektoren zu lokalisieren und lesbare Informationen wiederherzustellen, indem physische Festplattenfehler auf der gesamten Festplatte analysiert werden.