HDD-Test mit badblocks (Perl-Script)

[linuxCowboy]

Die erste Prüfung meiner neuen 3TB-Festplatte hat 60 Stunden gedauert! Da kam mir die Idee dass es doch cleverer wäre, programmgesteuert nur einen bestimmten Prozentsatz zu prüfen...

- dazu expliziet Anfang und Ende
- durch 4K-Sektoren und ohne Partitionen keine Faxen mit der Partition-Table
- einstellbare Ruhezeit zwischen dem lesen/schreiben der Stripes
- Startpunkt der Stripes zufällig wählbar, bei weiteren Durchläufen werden andere Sektoren geprüft
- optionale Temperatur-Überwachung
- Logfile

so entstand dieses Perlscript: 37262

Über USB-2 komme ich auf 13MByte/s (schreiben+lesen). Inzwischen habe ich eSATA mit ca. 60MB/s. Dauert aber immer noch. Als sie damit ein paar Stunden durchlief, zeigte smartctl einen Maxwert von 51 Grad. Daraufhin habe ich dann die Temperatur-Routine ergänzt. Damit ist es stabil bei 46 Grad.

Beispiel-Log: 37261

In den technischen Daten stehen bis 60 Grad. Darauf möchte ich es aber nicht ankommen lassen!

Schlüssig ist für mich die "Badewannen-Theorie". Am Anfang ist die Ausfallwahrscheinlichkeit groß, dann läuft sie ein paar Jahre gut durch, und am Ende geht sie wieder hoch wegen der Alterung.

Darum nehme ich sie auch erstmal gut ran, wenn auch nicht übermäßig.

Über USB gibts wohl keine Temperatur. Als Workaround nehme ich ein Infrarot-Thermometer. Die Werte am Gehäuse liegen 1-3 Grad unter dem Sensorwert.

Das Script ist, denke ich, gut verständlich. Oben im Header die Werte eintragen. Wird die Temperatur-Überwachung gewünscht, dann dafür sorgen, daß get_temp() auch einen Wert liefert. Mit smartctl klappt das bei mir meistens erst beim zweiten Aufruf.

Sollte erst nur ein schneller Hack werden. Habe aber gefallen daran gefunden!

Das Script ist gut getestet und optimiert. Trotzdem würde ich sehr gern die Meinung der Community hören!

Beim ruler dachte ich auch, Perl#64 wäre das Maß der Dinge. Eine Idee brachte die Sache wieder ins Rollen. Mit beeindruckendem Ergebnis, wie ich finde!

Außerdem von Leuten, die länger Linux und Perl machen als ich! (Hier wohl fast jeder

Und wie prüft ihr eigentlich eure Platten?

[Cae]

Und wie prüft ihr eigentlich eure Platten?

Geruch. Suche auf Sprueche_und_Zitate_aus_dem_Forum nach "ffel".

Aber ernsthaft, wenn's 'ne Austauschplatte fuer's RAID ist, mache ich vielleicht 'nen S.M.A.R.T.-short-Test oder gar nix. Ansonsten short/long-Test und badblocks -w (wobei man sich da auch prima Platten auf Vorrat testen kann).

Das Problem ist halt, dass man mit partiellem Testen moeglicherweise fuenf Sektoren neben 'nem kaputten vorbeigerutscht ist... aber "besser als nix" wuerde ich schon unterschreiben.

Gruss Cae

[linuxCowboy]

http://wiki.debianforum.de/Sprueche_und ... _dem_Forum

...das kommt wirklich gut!! Ist nur etwas versteckt unter "dieses und jenes"

Ein "badblocks -w" mit so einer externen USB2-Platte im geschlossenen Gehäuse... läuft doch mehrere Tage und ein Hitzeschaden ist damit fast sicher!??

wobei man sich da auch prima Platten auf Vorrat testen kann

Ich bin grad richtig gut drin im testen, was hier so rumschwirrt! Müßte auch mal die Pladde aus meinem DVD-Recorder ausbauen. Die hält schon sieben Jahre. Propritäres Format. Wenn die abraucht läuft das Teil erst gar nicht mehr an. (aber ich denke ich habe den Hack in der Tasche )

Wenn man eine HDD auf Verdacht prüfen will, die schon in Benutzung ist, wird es ein non-destructive read-write test. Also sichern, schreiben, lesen und prüfen, zurückschreiben. Und damit doppelt so lange wie eine normaler r/w-Test!

Mit dem eSATA ist's erträglich, finde ich. Dazu die Temperatur-Begrenzung. Die Backup-Platte wird erst richtig schön rangenommen. Und wenn sie das durchsteht, gibts die Daten. Vertrauensvoll.

[rendegast]

neuen 3TB-Festplatte
...
eSATA mit ca. 60MB/s.

aaahhh, Plattengeschwindigkeit dürfte einiges über hundert vielleicht sogar an zweihundert sein.
Vielleicht hat der esata-Anschluß eine Macke?
Oder der Controller in dem Extern-Gehäuse ist schlecht / macht Overhead?
Kabelkontrolle? geschirmt?

Aber der einzig richtige Test ist das schon angesprochene 'badblocks -[sv]w'.
(8 Lese- und Schreibvorgänge, JEDES Bit wird gedreht (0->1->0, 1->0->1))
Praktikabel im benutzten Zustand wäre Partitionierung oder vielleicht LVM,
wodurch dann zumindest Bereiche (nach Umkopieren) raw oder annähernd raw getestet werden könnten.
Und ein einziger Testlauf in akzeptabler Zeit abliefe.

wird es ein non-destructive read-write test. Also sichern, schreiben, lesen und prüfen, zurückschreiben.

Rate ich ernsthaft von ab, da die "Sicherung" im RAM liegt.
Und wenn Du auf wie auch immer geartete Fehler stoßen solltest, was passiert dann? Aua.
Zudem im Standard sind die Bereiche recht klein -> massenhafte Kopfbewegungen, schlechte Performance.
-> User wählt größere Bereiche, 100MB, 200MB, 500MB
-> annähernd lineare Leserate, aber auch größerer denkbarer Schaden.

Und zur Fehlereffizienz, gegenüber obigem erwischst Du statistisch nur jedes zweite Bit zum Kippen
(auf ein 0oder1 kommt ein 0oder1, das Drehen käme erst beim Zurückschreiben der "Sicherung").
Ein Bit alleine dürfte selten kaputt sein, meist wohl ganze Bereiche, aber immerhin.

[linuxCowboy]

Plattengeschwindigkeit dürfte einiges über hundert vielleicht sogar an zweihundert sein

Der Wert ist nur eine Orientierung für mich, wie lange ein do_scan() dauert. Einfach $size/$time. Bei r/w also ca. 1/2, bei n-r/w 1/4 der reinen Transferrate (wobei read und write sicher nicht gleich sind).

Dann kann ich die Werte besser abschätzen. z.B. 10%[$percent_to_check] von 3000GB[$blocks_total] sind 300GB. Bei 100 Stripes[$reads_total] sind das 3GB[$to_check] pro scan. Mit hier angezeigten 50MB/s käme ich auf ca. eine Minute/scan und gebe 60s für reguläre Pause[$sleep_between_reads]. Bei reinem read die Hälfte, bei non-destructive r/w das doppelte.

Vielleicht hat der esata-Anschluß eine Macke? Oder der Controller in dem Extern-Gehäuse ist schlecht / macht Overhead?

Neues 1m-Standard-eSATA-Kabel. Intern ein hochwertiges (teures!) Kabel von SATA an die Slotblende. Elektrisch also kein eSATA, und mit 1,5m Kabel leicht außerhalb der SATA-Spezifikation. Ist aber offenbar trotzdem so vorgesehen und ich kann mich da nicht beklagen.
Aber vielleicht liegt es daran, dass smartctl nicht richtig funktioniert?

Es kommt ständig
"Warning! SMART Attribute Data Structure error: invalid SMART checksum."
Auslesen kann ich die Werte mit "-t permissive"; wie schon geschrieben meist erst beim zweiten Mal gültige Werte.
Habe schon das aktuellste smartmontools kompiliert und Datenbank ist auch aktuell. Obwohl die 3TB nicht in der Datenbank ist, kommt bei welchen die es sind derselbe Fehler.

Aber der einzig richtige Test ist das schon angesprochene 'badblocks -[sv]w'. (8 Lese- und Schreibvorgänge, JEDES Bit wird gedreht (0->1->0, 1->0->1)

Ja, wenn man nur Parameter -w gibt, nimmt er default in 4 Durchläufen 0xaa, 0x55, 0xff, 0x00! Mit USB2 wäre das dann wirklich jenseits von Gut-und-Böse. So gebe ich einmal 0xFF. Wenn man bei einer neuen Platte 00 annehmen kann (?) wird auch jedes Bit gedreht.

non-destructive read-write test ... Rate ich ernsthaft von ab, da die "Sicherung" im RAM liegt.

Ja, habe ich mir auch schon überlegt. Würde ich nur machen, wenn ich von den Daten ein Backup habe. Und die "Backup-Platte" prüfen will, ob sie diesen Namen noch verdient. Dann allerdings richtig ausführlich - wenn man es nicht vorher schon gemacht hat!

Zudem im Standard sind die Bereiche recht klein

Ich habe mir überlegt, mit der Cache-Größe der HDD[$blocks_at_once] könnte ich richtig liegen. ca. 16MB/32MB.

Und zur Fehlereffizienz, gegenüber obigem erwischst Du statistisch nur jedes zweite Bit zum Kippen

Guter Gedanke! Beim non-destructive Test braucht man die doppelte Zeit und hat nur die halbe Wirkung!

Also, neue Platten sofort prüfen. Im offenen eSATA-Adapter. Proaktiv Pausen einplanen. Die Jungs, die badblocks programmiert haben, sehen das wohl auch so, und haben mit "-d read delay factor" einen Pause-Parameter eingebaut. Könnte man sicher auch irgendwie im Script nutzen.

[rendegast]

Der Wert ist nur eine Orientierung für mich, wie lange ein do_scan() dauert. Einfach $size/$time.

Eine andere Informationsquelle wäre 'smartctl -c', die Zeit für den langen Test.
Bei mir angegeben 171Minuten, entspräche 93MB/s overall.
Die bei diversen Platten so angegebenen Zeiten paßten eigentlich immer recht gut,
wurden wohl in Testdurchläufen ermittelt.

Es kommt ständig
"Warning! SMART Attribute Data Structure error: invalid SMART checksum."
Auslesen kann ich die Werte mit "-t permissive"; wie schon geschrieben meist erst beim zweiten Mal gültige Werte.

Wenn die Platte direkt intern angeschlossen solche Meldungen nicht ausgibt,
macht wohl der Controller des Externgehäuses oder die eSATA-Karte(?) Probleme.

So gebe ich einmal 0xFF. Wenn man bei einer neuen Platte 00 annehmen kann (?) wird auch jedes Bit gedreht.

0->1 nenne ich gekippt, für gedreht müßte nochmal 0x00 drüber.

[cirrussc]

Über USB-2 komme ich auf 13MByte/s (schreiben+lesen). Inzwischen habe ich eSATA mit ca. 60MB/s.

Wie rendegast schon schrieb, liegt das eher vllt. an einem Controller vor der HDD. Oder das ist nicht die Rohtransferrate sonderndie vom FS. Selbst 5400rpm Platten schaffen über 100 MB/s bei (e)SATA.

Darum nehme ich sie auch erstmal gut ran, wenn auch nicht übermäßig.
[...]
Und wie prüft ihr eigentlich eure Platten?

Das sehe ich anders. Eine Festplatte sollte gerade unter Vollast eine Weile fehlerfrei laufe! Wenn das so nicht möglich ist, dann liegt das eventuell an verhinderter Wärmeabfuhr oder anderen Defekten/Effekten; im Betrieb ist so eine Dauerlast privat zwar unwahrscheinlich, doch sollte sie das aushalten.
Deswegen ist ein kompletter Test mit badblocks (zudem das schnellste) das richtige Mittel.
Außerdem mache ich die SMART Selbsttets zusätzlich.

Über USB gibts wohl keine Temperatur. Als Workaround nehme ich ein Infrarot-Thermometer. Die Werte am Gehäuse liegen 1-3 Grad unter dem Sensorwert.

Hängt komplett davon ab, wie gut die ATA Bridge umgesetzt ist.
Tip: USB3 Konverter machen das sehr vorbildlich.

[linuxCowboy]

Eine andere Informationsquelle wäre 'smartctl -c', die Zeit für den langen Test.

Die smartctl-Tests laufen hier leider auch nicht durch.

macht wohl der Controller des Externgehäuses oder die eSATA-Karte(?) Probleme.

Das denke ich auch. Aber ihn deswegen zurückgeben...? Ich war so froh dass ich endlich über 2TB lesen kann, und dass es mit eSATA endlich vorwärts geht! Und wer weiß, ob es beim nächsten besser ist...

gekippt...gedreht

Gute Differenzierung! Wenn man es so sieht macht plötzlich auch dieser überteure default-scan Sinn.

Ich habe gerade mal nachgescheut, badblocks gibts mind. seit 1997. Ob damals auch schon die vier Musterscans default waren? So schnell bzw. langsam wie's damals intern ging ist heute USB2! (ein Januskopfsmilie [lachen und weinen zugleich])

[rendegast]

Die Platten waren aber auch um Faktor 1000 kleiner.

Die smartctl-Tests laufen hier leider auch nicht durch.

Diese führt die Platte selbsttätig aus,
wenn das nicht funktioniert ist ein Plattenfehler wahrscheinlich.

[linuxCowboy]

Oder das ist nicht die Rohtransferrate sonderndie vom FS. Selbst 5400rpm Platten schaffen über 100 MB/s bei (e)SATA.

Wie schon geschrieben ist das einfach $size/$time. Da das ein read/write-Test war also ungefähr mal zwei. Jedenfalls bedeutend mehr als mit USB2.

Eine Festplatte sollte gerade unter Vollast eine Weile fehlerfrei laufen

Ja sicher, aber wie lange ist eine Weile? Und welche Temperatur?

Bei einer Backup Platte könnten wir wie gesagt mit eSATA sogar über den vollen write-Test reden. Wenn sie den gut durchsteht, betrachte ich meine Daten dann als relativ sicher. Sie wird dann ja nicht mehr so viel benutzt. Bei einer normalen PC-Platte würde ich nur einige Prozent prüfen und gut ist.

Und die 50Grad die ich hier hatte sind mir eigentlich schon zuviel. Geschweige denn dass ich auf die 60 zugehe, die sie ja laut Datenblatt auch abkönnen sollte. Schreibt nicht die c't dass 50 Grad im Rechner schon nicht mehr gesund sind?

Wenn ich inzwischen diese schicken externen Festplattengehäuse sehe, erscheint sofort "Wärmetod" vor meinem geistige Auge!

Über USB gibts wohl keine Temperatur...

Hängt komplett davon ab, wie gut die ATA Bridge umgesetzt ist.
Tip: USB3 Konverter machen das sehr vorbildlich

Hmm, ich habe hier USB3 dran, kann's aber zur Zeit nicht prüfen. Über USB2 kommt jedenfalls nix. Und du kennst USB2-Adapter die smart-Werte und Temperatur liefern?

Das hängt sicherlich von einigen Sachen ab... Hard- und Software... wenn du Fakten, würde mich das interessieren!

[linuxCowboy]

Die smartctl-Tests laufen hier leider auch nicht durch.

Diese führt die Platte selbsttätig aus,
wenn das nicht funktioniert ist ein Plattenfehler wahrscheinlich.

Das Wichtigste für mich steht gleich am Anfang:
SMART overall-health self-assessment test result: PASSED

Wenn ich Tests anstoße kommt:
Short captive Interrupted (host reset) 90%

Aber ist nicht bei S.M.A.R.T. vieles kann und wenig muss?
Ständig wechselnde Ausgaben, viele Fehlermeldungen, die Sache ist kein Ruhmesblatt!

Zurückschicken werde ich sie aber deswegen wohl nicht. Ich werde vielleicht noch einen Belastungstest machen. Wenn sie den übersteht, akzeptiere ich sie.

[rendegast]

Das Wichtigste für mich steht gleich am Anfang:
SMART overall-health self-assessment test result: PASSED

Aus eigener Erfahrung, bedeutet eigentlich nichts,
nur daß die smart-Routinen funktionieren (sollen).
Steht so auch bei einer Platte mit pending Sectors.

Wenn ich Tests anstoße kommt:
Short captive Interrupted (host reset) 90%

Mach es ohne '-C', da der Test dann ohne Verbindung zum Host abläuft,
welche auf diesem Rechner wohl Probleme hat.
Dann kann beobachtet werden mit zBsp.

Code: Alles auswählen

watch -n 10 'smartctl -c /dev/sda | grep execution -A1'

Diese Nachfragen lassen den laufenden Test aber stocken, also nicht zu häufig absetzen.

[linuxCowboy]

smart-Routinen...

Ich danke dir für deine Bemühungen, aber es führt zu nichts. "execution" kommt in der Ausgabe gar nicht vor. Nicht implementierte Feature, Fehlermeldungen, wechselnde Ausgaben. Ohne "-T permissive" geht meist gar nichts.

Ich halte mich an die Schreibtests. Und freue mich dass mein Programm gut durchläuft. z.B. ist gerade ein 50%-Test zu 3/4 durch.
Das zählt für mich. smart is stupid!

Vielleicht ja auch ich selbst. Ich lasse mir jedenfalls von diesem halbgaren Zeug nicht länger meine Zeit stehlen!

[cirrussc]

Die smartctl-Tests laufen hier leider auch nicht durch.

Wie rendegast schon sagt, wenn die internen Test nicht fehlerfrei durchlaufen ist etwas im argen. Deiner wurde abgebrochen, klar bei einem Reset und bei dem unüblichen captive Test.
Wichtig sind der short und long Test.

Ja sicher, aber wie lange ist eine Weile? Und welche Temperatur?

Ich würde so einen erfolgreichen kompletten badblocks Durchlauf als recht passabel ansehen. Wie gesagt sollten die Temperaturen nicht über die Herstellermaxima reichen; wenn doch, dann sollte man sich etwas anderes bezüglich der Kühlung einfallen lassen (anderes Gehäuse, Luftkühlung usw.).

Hmm, ich habe hier USB3 dran, kann's aber zur Zeit nicht prüfen. Über USB2 kommt jedenfalls nix. Und du kennst USB2-Adapter die smart-Werte und Temperatur liefern?

Das hängt sicherlich von einigen Sachen ab... Hard- und Software... wenn du Fakten, würde mich das interessieren!

Ich meine damit die USB Bridge Controller der externen Gehäuse, welche USB3 tauglich besser die ATA pass through Übersetzung unterstützen.
Welche definitiv, wie und wie gut, welche nicht, unterstützt werden, das ist hier zusammengefasst [1].

Aber ist nicht bei S.M.A.R.T. vieles kann und wenig muss?
Ständig wechselnde Ausgaben, viele Fehlermeldungen, die Sache ist kein Ruhmesblatt!

Das zählt für mich. smart is stupid!

Vielleicht ja auch ich selbst. Ich lasse mir jedenfalls von diesem halbgaren Zeug nicht länger meine Zeit stehlen!

SMART ist eigentlich sehr hilfreich.
Dass bei dir eben nicht alles unterstützt wird hat nichts mit SMART sondern dem angesprochenen USB Bridge Chip zu tun.

Zu den Smartmontools hatte ich unter Festplattendiagnostik- und Überwachung etwas im Wiki hinterlassen.

[1] http://sourceforge.net/apps/trac/smartm ... SB-Devices

[linuxCowboy]

Wichtig sind der short und long Test.

Ich muss mich korrigieren. Wenn ich den Parameter "-d sat" expliziet angebe, liefert smartctl auch über USB vernünftige Daten. Und ich kann die Temperatur auslesen!

Es ist sogar besser als über eSATA. Die ständigen Checksum-Error fallen weg.

Warning! SMART Attribute Data Structure error: invalid SMART checksum.

Das Auslesen klappt beim ersten Mal. Der short-Test läuft erfolgreich:

Short offline Completed without error 00%

Ich bekomme saubere Ausgaben mit -a, -A und -x. Ohne -T permissive. Das beweist dass es (prinzipiell) geht.

Bliebe ja dann nur noch das Kabel. Ich kann das interne SATA nicht ungestraft auf 1,5m verlängern!??

Andererseits, ich habe bis jetzt ca. 8TB geschrieben und gelesen. Ohne Fehler.

Wenn die Daten auf dem Kabel verfälscht werden, müßte das doch noch jemand anders mitbekommen als der smartctl CRC-Check? Und sich bemerkbar machen!

Wie gesagt sollten die Temperaturen nicht über die Herstellermaxima reichen;

Über -x lese ich aus:

Min/Max Temperature Limit: -40/70 Celsius

Den Test würde ich mal machen wollen - bei -39 und +69 Grad!

Zu den Smartmontools hatte ich unter Wiki-Artikel zum Thema Festplattendiagnostik- und Überwachung etwas im Wiki hinterlassen.

Ja, das Wiki ist sehr gut und ausführlich. Gute Arbeit! Genauso wie das über hdparm und badblocks.

... "etwas hinterlassen" ist gut. Sieht so aus als hättest du das fast alles allein gechrieben...

[linuxCowboy]

Nach dem Erfolg mit USB habe ich mir das doch nochmal angeschaut. Wieso findet smartctl CRC-Errors wenn ich sonst Terabyte fehlerfrei schreibe und prüfe? Vielleicht gehen die Test-Bytes gar nicht als Daten übers Kabel, sondern nur als kurzer Befehlscode. Etwa "schreibe einen Block 0xFF" statt 4096 mal FF. Oder gleich "schreibe ganzen Puffer FF".

badblocks hat einen Test "random". Damit muss er jedes Byte einzeln übertragen.

Also den Test ins Script eingebaut und - jede Menge badblocks! Zigtausend. Über eSATA und über USB.

Damned. Alles nur Schrott!

Dann fiel mir auf, dass da gerade Zahlen vorkommen, 4000 Blocks oder 8000 Blocks. Außerdem stellte ich fest, dass die Größe des blocks_at_once-Parameter das Ergebnis beeinflußt wenn er durch 8 teilbar ist (bs & ~7). Das sollte aber nicht mein Problem sein und schon gar nicht diese Fehler verursachen.

Also habe ich mir von sourceforge die neueste Version kompiliert und voila, Schrott wieder okay.

Die e2fsprogs fackeln übrigens nicht lange und setzen sich mit "make install" in die erste Reihe mit /sbin, /bin usw. und überschreiben ihre buggy-Vorgänger.

Jetzt läuft also der random Test genauso wie die Mustertests.

Nächste Woche schließe ich eSATA mal normgerecht mit unter 1m Gesamtlänge an.

Außerdem habe ich bei dem Script noch den hdparm-Ausdruck angepasst, denn über USB herrscht da schon die nächste Eiszeit:

drive temperature (celsius) is: under -20
drive temperature in range: yes
(zum Glück ist das drive ja bis -40 Grad spezifiziert

Und die Status-Ausgabe enthält jetzt auch die Anzahl gelesener Blocks, damit sie bequem mit der Anzahl eventueller bad blocks verglichen werden kann.

Code: Alles auswählen

Checking for bad blocks in read-write mode
From block 709549655 to 709793843
Testing with random pattern: done                                                 
Reading and comparing: done                                                 
Pass completed, 0 bad blocks found. (0/0/0 errors)
30/30: 953MB (244.189 blocks) in 64s ==> 14MB/s  [0:48:58]
44 degrees Celsius

Das "0/0/0 errors" ist von der neuen badblocks-version. [read errors / write errors / data- corruptions]

bb-test-2013-07-06.pl 37278

Wieso aber smartctl CRC-Fehler meldet und dann trotzdem sinnvolle Daten ausgibt bleibt mir weiterhin schleierhaft!

[cirrussc]

Wieso findet smartctl CRC-Errors wenn ich sonst Terabyte fehlerfrei schreibe und prüfe? Vielleicht gehen die Test-Bytes gar nicht als Daten übers Kabel, sondern nur als kurzer Befehlscode. Etwa "schreibe einen Block 0xFF" statt 4096 mal FF. Oder gleich "schreibe ganzen Puffer FF".

Das SMART der HDD loggt die CRC Fehler als absoluten Zähler aller bisherigen Fehlerereignisse. Wenn also aus irgend einem Grund (meist temporäre Signalstörungen) Bus-Übertragungsfehler (CRC) aufgetreten sind, dann werden diese (sollten) im SMART Attributt DMA_CRC_Error_Count aufgeführt. Sind diese also einmal angefallen, muss das nicht bedeutet, dass sie permanent auftreten.

Die Daten werden Sektorweise (ungeachtet der FS-Blockgröße) von der HDD gelesen und auf sie geschrieben, egal ob da nur ein einziges Bit verändert wird. Das funktioniert nicht anders.

[linuxCowboy]

fix off-by-one bug:

bb-test-2014-03-05.pl: 37697

Man kann damit auch sehr gut 100% eines USB-Sticks püfen.