PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Badblocks meldet nicht reproduzierbare Fehler in /dev/ram0, /dev/loop0



Noether
31.12.10, 09:52
Beim Testen von Ramdisk zeigt badlocks merkwürdigerweise Fehler:



> badblocks -wsv -c 65536 -t random /dev/ram0
Durchgang beendet, 65536 defekte Blöcke gefunden.


wobei diese Blöcke 100 % bedeuten.

Beim Default-Durchlauf (ohne -t random), mit den Mustern 0xaa, 0x55, 0xff und 0x00 werden nur beim ersten Durchlauf Fehler gemeldet :confused:
Wird die Ramdisk gemountet und ein Schreib-Lesetest mit einer Datei gemacht, zeigen sich keine Fehler.

Ähnlich ist es mit einem USB-Stick, den ich mittels losetup verschlüsselt habe: Ein



badblocks -wsv -c 65536 -t random /dev/loop0


zeigt um 0,1 % defekte Blöcke, während ein Test mit dem Stick direkt, also /dev/sdb, keinen Fehler zeigt! :eek:

Wie kann das sein? :confused:

oziris
31.12.10, 10:07
Ehrlich gesagt würde es mich eher wundern, wenn es überhaupt funktionieren würde.

Noether
31.12.10, 11:28
Ehrlich gesagt würde es mich eher wundern, wenn es überhaupt funktionieren würde.

Wieso? :confused:

bla!zilla
31.12.10, 12:03
Weil badblocks kaum dafür ausgelegt sein dürfte, Blöcke innerhalb einer Ramdisk zu überprüfen. Falsches Tool. Ein Block auf einer Disk ist eben was anderes, als ein Block in einer Ramdisk.

oziris
31.12.10, 15:47
Weil badblocks für Datenträger ist.
Du willst Deinen RAM testen? Dann teste keine Ramdisk mit badblocks, sondern benutze sowas wie memtest.
... aber warum sollte man mit badblocks ein (verschlüsseltes) Loop-Device testen?
Du willst das Device testen, aus dem das Loop-Device erstellt wird? Dann prüfe eben das und nicht das Loop-Device.

Ich weiß nichtmal genau, wie badblocks funktioniert (weil ich zu faul bin den Code zu lesen), dennoch wundert es mich gar nicht, dass diese abstrakten Versuche scheitern.

Wenn ich wissen will, ob die Milch noch gut ist, dann Koche ich auch nicht zuerst einen Pudding aus ihr, um dann zu prüfen, ob der Pudding gut ist. Das wäre nicht nur unnötige Arbeit, es würde auch das Ergebnis der Überprüfung verfälschen, weil die Milch dazu abgekocht werden muss und die anderen Zutaten Geruchs- und Geschmackstests beeinflussen könnten.

Noether
31.12.10, 16:09
Weil badblocks für Datenträger ist.
Du willst Deinen RAM testen? Dann teste keine Ramdisk mit badblocks, sondern benutze sowas wie memtest.


Und was nimmt man denn für Ramdisks und Loop-Devices? :confused:




... aber warum sollte man mit badblocks ein (verschlüsseltes) Loop-Device testen?


Ganz einfach: Über losetup legt man zuerst ein Loop-Device an und dann über mkfs ein Dateisysstem.
Ist nur das Dateisystem neu zu machen, wäre es doppelter Aufwand auch das Loop-Device neu zu machen.
Deshalb habe ich nur das Loop-Device getestet.




Ich weiß nichtmal genau, wie badblocks funktioniert (weil ich zu faul bin den Code zu lesen), dennoch wundert es mich gar nicht, dass diese abstrakten Versuche scheitern.


Wie man im Sourcecode nachlesen kann, wird einfach ein Muster reingeschrieben bis das Device voll ist und dann wird ausgelesen und verglichen.
Das muss im Prinzip immer funktionieren, auch bei Ramdisks und Loop-Devices, denn ansonsten würden die Daten darin korrupt/verändert.

oziris
31.12.10, 16:23
Und was nimmt man denn für Ramdisks und Loop-Devices? :confused:Ggf. kannst Du das enthaltene Dateisystem mit fsck prüfen. ... oder wie gesagt memtest für den RAM.


Ganz einfach: Über losetup legt man zuerst ein Loop-Device an und dann über mkfs ein Dateisysstem.
Ist nur das Dateisystem neu zu machen, wäre es doppelter Aufwand auch das Loop-Device neu zu machen.
Deshalb habe ich nur das Loop-Device getestet.Verstehe; auch wenn ich nie auf sowas gekommen wäre. Für mich ist irgendwie einfach klar, dass man badblocks in so einem Fall nur auf die Partition anwendet, aus der man das Loop-Device erstellt. Erstellt man es aus einer Datei, dann würde ich entsprechend auch die Partition testen, auf der das Dateisystem liegt, welches die Datei enthält.



Wie man im Sourcecode nachlesen kann, wird einfach ein Muster reingeschrieben bis das Device voll ist und dann wird ausgelesen und verglichen.
Das muss im Prinzip immer funktionieren, auch bei Ramdisks und Loop-Devices, denn ansonsten würden die Daten darin korrupt/verändert.Du kannst ja vielleicht einen Bug-Report dazu schreiben, wenn Du meinst, dass es gehen sollte. Man wird Dir dann bestimmt sagen, wenn das nicht gewollt ist bzw. warum es im Detail nicht geht.