Plattentest für Linux?

Google kennst Du?

"h2test linux" bzw. "h2testw linux" bringt ganz tolle Treffer - u.a. 
auch in diesem Forum...

Ähm, mal abgesehen davon, dass das relativ fragwürdig ist, weil bei 
USB-Sticks (und Festplatten) in aller Regel keine feste Zuordnung 
zwischen logischen Blöcken und physikalischen Blöcken hat, und weil die 
Geräte in aller Regel selbst kaputte Blöcke erkennen.

Aber da ist alles eigentlich trivial, zum Beispiel kannst Du so 
vorgehen:

dd if=/dev/random of=datei bs=1M count=1024
#Schreibt Dir 1024 1 Megabyte Blöcke in die Datei "datei"

md5sum datei
#Macht über die Datei eine Prüfsumme

dd if=datei of=/dev/sdx
#/dev/sdx ist die Gerätedatei Deines USB-Sticks, zum Beispiel /dev/sdb, 
in aller Regel ist dass der letzte Buchstabe da drin. Tab ist Dein 
Freund

md5sum /dev/sdx
#macht eine Prüfsumme über das Geräte wenn die mit der oben identisch 
ist, ist alles OK

Es gibt auch noch badblocks, dass kann auch so was, nimmt aber beliebige 
Daten anstelle von Zufallsdaten. Dafür kann es auch den viel 
sinnvolleren nur-lesen Test machen und hat noch andere Features. Mit
man badblocks
kriegst Du die Handbuchseite dazu.

Christian Berger schrieb:
> Ähm, mal abgesehen davon, dass das relativ fragwürdig ist

Nein, das ist nicht fragwürdig, weil damit Macken im Controller des 
Sticks auffallen - genau darum gehts in meinem Fall.

Aber aus der Tatsache, daß es da nichts fertiges dafür gibt, muß man 
wohl schließen, daß spinnerte USB-Sticks kein Problem unter Linux sind 
;-)

Uhu Uhuhu schrieb:
> Aber aus der Tatsache, daß es da nichts fertiges dafür gibt

Gibts doch, heisst F3:
http://oss.digirati.com.br/f3/

Matthias Sch. schrieb:
> Gibts doch, heisst F3:
> http://oss.digirati.com.br/f3/

Das Ding schreibt Dateien in ein bestehendes Dateisystem - daraus folgt, 
daß nicht der gesamte Speicher getestet wird.

Christian Berger schrieb:
> dd if=/dev/random of=datei bs=1M count=1024
> #Schreibt Dir 1024 1 Megabyte Blöcke in die Datei "datei"

hierzu noch 2 Verbesserungsvorschläge:

- nimm /dev/urandom, das dürfte deutlich schneller sein weil es keine 
echten Zufallswerte braucht sondern nur den Pseudozufallsgenerator 
verwenden.

- nicht bei 1024*1M = 1G aufhören, sondern entsprechend vergrößern daß 
sicher der gesamte stick vollgeschrieben wird.

Das ist ein zwei-Zeilen-Shellscript -- kein Mensch würde für sowas ein 
Programm schreiben und sich die Mühe machen das zu packagen und zu 
dokumentieren ;)

Ist ja jetzt auch nicht gerade eine Standardanwendung, die Joe User 
jeden Tag dreimal braucht.

Sven B. schrieb:
> Ist ja jetzt auch nicht gerade eine Standardanwendung, die Joe User
> jeden Tag dreimal braucht.

Wenn das das Kriterium dafür wäre, in den Fundus von Linux zu kommen, 
dann wäre der etwa so mickrig, wie das, was Windows da zu bieten hat...

Martin H. schrieb:
> Google kennst Du?

Ich rechne damit, daß die Teilnehmer hier im Schnitt gute Tipps geben 
können - bessere, als Google ;-) Wenn du das nicht kannst, dann laß es 
einfach.

Stimmt, aber die meisten Tools in dem Fundus sind relativ elementar. dd 
zum Beispiel ist unglaublich flexibel, dafür gibt es tausende 
Anwendungsmöglichkeiten. Ein Tool hingegen, welches Zufallsdaten auf 
einen USB-Stick schreibt und dann wieder zurückliest und die Prüfsummen 
vergleicht... nun ja, die möglichen Anwendungen dafür sind doch relativ 
beschränkt.

Falls die Prüfsummen nicht übereinstimmen kannst du sowas machen wie
for image in image1 image2; do cat $image.img |hexdump -C > 
$image.img.hex;
diff image1.img.hex image2.img.hex
um herauszufinden wo genau die Unterschiede sind. Evtl. ist es aber 
sinnvoll, die images vorher in ein paar kleine Teile zu zerlegen und die 
Prüfsummen zu vergleichen, denn sonst wird das ziemlich... groß. ;)

Grüße,
Sven

Steffen schrieb:
> ich hatte auch grad einen defekten Intenso USB Flash Stick in den
> Händen: Kapazität ca. 8 GB, die ersten knapp 4 GB sind ok.

Meiner ist ein Intenso 16 GB von R. Ich hatte ihn - wie üblich - als 
erstes mit h2testw geprüft und keine Probleme gefunden. Dann lag er 
lange unbenutzt herum, bis ich einen Ubuntu 12.04 Server darauf 
instalierte.

Der lief eine Weile, bis plötzlich sudo in der include-Zeile ganz am 
Ende von /etc/sudoers einen Syntaxfehler fand.

Ich konnte dort zwar per Editor nichts finden und das Verzeichnis nebst 
Inhalt, das dort eingelesen werden soll, existierte mit dem erwarteten 
Inhalt, aber der Fehler war reproduzierbar.

Anschließend ging es mit dem Teil rapide bergab.


Eigentlich ist dd für so einen Test nicht sehr geeignet. Besser wäre ein 
Mock-Random-Generator, der einen Datenstrom erzeugen und auf einen 
/dev-File schreiben und ihn anschließend wieder lesen und mit dem Output 
des mit dem alten Seed neu gestarteten Zufallsgenerators vergleicht und 
bei Abweichungen die Sektor-Adressen ausgibt.

Für mich hört sich das an wie eine kompliziertere Möglichkeit, um genau 
dasselbe zu erreichen... ich bezweilfe sogar, dass es schneller ist. Es 
braucht nur weniger Plattenplatz, aber der ist ja heutzutage billig.

Sven B. schrieb:
> Für mich hört sich das an wie eine kompliziertere Möglichkeit, um genau
> dasselbe zu erreichen... ich bezweilfe sogar, dass es schneller ist. Es
> braucht nur weniger Plattenplatz, aber der ist ja heutzutage billig.

Also ich schätze, daß das Ding mit max 50 Zeilen C zu erledigen ist.

Es könnte auch etwas schneller, als die dd-Methode sein, weil 
Latenzzeiten auf dem Datenträger, der die Vergleichsadtei hält und der 
Systemoverhead nicht anfallen und ein primitiver Kongruenzgenerator mit 
Sicherheit ein vielfaches schneller ist, als die gleiche Menge Daten von 
und zu einem externen Datenträger zu transportieren.

Letztlich wird der USB-Stick die Geschwindigkeit vorgeben.

> braucht nur weniger Plattenplatz, aber der ist ja heutzutage billig.

Sorry, aber das ist ein selten blödes Argument: wenn der entsprechende 
Plattenplatz nicht verfügbar ist, dann kannst du dir nichts dafür 
kaufen...

Wir können ja mal ausprobieren, wieviele USB-Sticks ich mit der 
dd-Methode testen kann, bis dein C-Programm funktioniert ;)

Natürlich ist das nicht die eleganteste, schnellste vorstellbare Lösung, 
aber dafür hat man sie halt in 30 Sekunden gebastelt.

Falls du den Plattenplatz wirklich nicht hast, kannst du den Test ja mit 
einer weiteren Zeile bash in 20 kleine Teile zerlegen.

Grüße,
Sven

Steffen schrieb:
> ich hatte auch grad einen defekten Intenso USB Flash Stick in den
> Händen: Kapazität ca. 8 GB, die ersten knapp 4 GB sind ok. Darüber
> schlagen BIOS LBA Zugriffe fehl.

Das hört sich jetzt eher nach einem Problem vom BIOS an.

Gerd E. schrieb:
> hierzu noch 2 Verbesserungsvorschläge:
>
> - nimm /dev/urandom, das dürfte deutlich schneller sein weil es keine
> echten Zufallswerte braucht sondern nur den Pseudozufallsgenerator
> verwenden.

Ja, aber der Vorposter wollte unbedingt Zufallszahlen.

> - nicht bei 1024*1M = 1G aufhören, sondern entsprechend vergrößern daß
> sicher der gesamte stick vollgeschrieben wird.

Das sollte klar sein.

Christian Berger schrieb:
> Das hört sich jetzt eher nach einem Problem vom BIOS an.

h2test wurde ursprünglich mal entwickelt, weil irgend welche Ganoven den 
Markt mit USB-Sticks geflutet hatten, die nur einen Teil des gemeldeten 
Speichers enthielten und die fehlenden Blocks einfach auf die 
vorhandenen umleitete.

Diese Art "Fehler" könnte man auch als BIOS-Problem abtun...

Nur: wären es wirklich BIOS-Probeme, dann würde der Fehler mit allen 
möglichen USB-Datenträgern auftreten und nicht nur mit dem einen.

Sven B. schrieb:
> Natürlich ist das nicht die eleganteste, schnellste vorstellbare Lösung,
> aber dafür hat man sie halt in 30 Sekunden gebastelt.

Im Prinzip ist das sogar mit einem C-Fünfzeiler zu erledigen, wenn er 
seine Daten über stdin/out schickt und dd als Schnittstelle zu Platte 
benutzt wird.

Deswegen wunder es mich doch schon etwas, daß es unter Linux allerlei 
hoch trickreiche Entropiequellen gibt, aber dieses Promivst-Teil 
nicht...

Steffen schrieb:
> Kannst Du dazu bitte eine Quelle nennen? Habe noch nie was von Problemen
> bei LBA Zugriffen jenseits von 4 GB gehört

Ich weiß jetzt nicht ob die Grenze genau bei 4 Gb war, aber früher hat 
man die boot-Partition von Linux immer ganz an den Anfang gepackt damit 
das Funktioniert. Ich weiß noch, dass ich mal ein Mainboard mit AMD K6 
(oder so) hatte, das definitiv schon LBA benutzt hat aber meine 60Gb 
Platte nur mit ein paar Gigabytes angezeigt wurde.

Es kann sein, dass das dieses alte Problem hier war:
http://www.linux-sxs.org/administration/limits.html
Das war allerdings bei 8Gb, zeigt aber den Murks den man damals auch bei 
LBA machen hat müssen.

Und ich glaube auch nicht, dass die BIOS Hersteller sich da große Mühe 
geben den BIOS Zugriff auf USB-Medien ordentlich zu implementieren, denn 
den braucht jetzt wirklich keiner mehr. (bis auf die ersten paar 
Sektoren zum Booten)

Uhu Uhuhu schrieb:
> Im Prinzip ist das sogar mit einem C-Fünfzeiler zu erledigen, wenn er
> seine Daten über stdin/out schickt und dd als Schnittstelle zu Platte
> benutzt wird.

Oder Du greifst direkt auf die Gerätedatei zu. Die ist auch nicht viel 
anders als eine große Datei.

Christian Berger schrieb:
> Oder Du greifst direkt auf die Gerätedatei zu. Die ist auch nicht viel
> anders als eine große Datei.

dd bringt die Fehlerbehandlung mit - die ist wohl kam mit ein paar 
Zeilen zu erledigen...

Richi schrieb:
> Uhu Uhuhu schrieb:
>> Deswegen wunder es mich doch schon etwas, daß es unter Linux allerlei
>> hoch trickreiche Entropiequellen gibt, aber dieses Promivst-Teil
>> nicht...
>
> Weil es in Form von dd schon vorhanden ist und es keine Notwendigkeit
> gibt dafür extra ein Programm zu schreiben.

Wer lesen kann, ist klar im Vorteil...

Hier ist das Spielzeug: 
Beitrag "Pseudo-Zufallsdatenquelle/senke für Medientests unter Linux"

Mein USB-Stick läßt sich mittlerweile nicht mehr beschreiben.