Ich suche ein Linux-Tool, das einen USB-Stick ohne Dateisystem mit Zufallsdaten vollschreiben und die Daten kontrolllesen kann - so was ähnliches, wie h2test für Windows.
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.
Uhu Uhuhu schrieb: > 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 > ;-) Hm, komisch, also ich finde mit den googletipps im 2. beitrag und den seiten der in den ersten 3 Beiträgen beschriebenen Programmen mehrere Alternativen ;-)
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
> Ich rechne damit, daß die Teilnehmer hier im Schnitt gute Tipps geben > können - bessere, als Google ;-) Da bist du hier im falschen Forum. Hier gibt es fast nur Computeranalphabeten und Windowsklicker.
Uhu Uhuhu schrieb: > 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. Ich rufe auch stets die PTB an und frage die nach der Uhrzeit -- die kennen sich aus und haben die genauesten Uhren. Aber seltsam -- seit einiger Zeit hebt da keiner mehr ab, haben wohl gerade Ferien.
Uhu Uhuhu schrieb: > 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. Ok, dann gebe ich die einen besseren Tip als Google und dieses Forum zusammen: Kauf dir einen neuen USB Stick.
Hallo Uhu Uhuhu, 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. "Interessanterweise" erkennt Linux den Fehler nicht (Debian 3.2.35/64). Ein 8 GB Image (aus /dev/urandom generiert) wird von dd ohne Fehlermeldung auf den Stick geschrieben, und von dd auch ohne Fehlermeldung wieder ausgelesen. Erst wenn man die Images vergleicht, dann erkennt man dass knapp vor 4 GB Schluss ist (alle Werte drüber sind FF, Vergleich der Images mit "cmp -l"). Vorgehensweise also: Aus /dev/urandom Image erzeugen. Mit dd auf den Stick schreiben, mit dd wieder auslesen (ggf dd_rescue statt dd, bei Schreib- oder Lesefehlern). Danach mit cmp -l die beiden Images vergleichen. Grüße, Steffen
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...
Hallo Christian, Christian Berger schrieb: > Das hört sich jetzt eher nach einem Problem vom BIOS an. Kannst Du dazu bitte eine Quelle nennen? Habe noch nie was von Problemen bei LBA Zugriffen jenseits von 4 GB gehört Den 32 bit LBA Überlauf findet man dagegen häufig, aber da sind wir schon bei 2 TiB. Bei älteren Boards (pre 2005) gibt es ein 237 GiB Problem im BIOS. Alles davor sind imho CHS (Size,Translation) oder MBR Problematiken. Grüße, Steffen
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.
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...
Hallo Christian, Christian Berger schrieb: > 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. Das waren keine LBA sondern CHS Probleme bei der IDE CHS - BIOS CHS Translation. Bei der BIOS LBA Adressierung (int 13/4x wird kein CHS verwendet). > 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) Aha. Quelle? Ich habe hier 7 Mainbaords aus 2005-2013. Die können das alle. Egal ob externe HDD oder USB Flash. Womit wir zurück beim Thema sind: Mein BIOS erkennt des Problem mit dem kaputten USB Stick. Während es iwo im Linux Kernel klemmt (oder in dd, halte ich aber für weniger wahrscheinlich). Der liest und schreibt einfach Adressen ohne Fehlermeldung obwohl der USB Stick Fehler meldet. Grüße, Steffen
Hier ist das Spielzeug: Beitrag "Pseudo-Zufallsdatenquelle/senke für Medientests unter Linux" Mein USB-Stick läßt sich mittlerweile nicht mehr beschreiben.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.