Antworten:
Bewerben ddund trzur virtuellen Inspektion:
dd if=/dev/sdb | tr '\0' 0
Bewerben ddund grepzur automatischen Prüfung:
dd if=/dev/sdb | grep -zq . && echo non zero
Das Obige ist deutlich langsamer als der unten stehende optimierte Befehl:
grep -zq . /dev/sdb && echo non zero
grep -zliest nullbegrenzte Zeilen ein. Wenn alle Bytes null sind, ist jede Zeile leer und .sollte daher niemals übereinstimmen.
Dies gilt natürlich nicht für eine formatierte Partition - das Formatsystem verwendet einige Bytes und sie sind nicht null.
hexdumpkönnte schneller sein.
bs, damit es nicht byteweise ausgeführt wird.
Ich werde auch hier meinen Hut in den Ring werfen. Eine Alternative, die ich gerne benutze, ist scrub. Es befindet sich in den Repositorys. Um es über ein Terminalfenster zu installieren, geben Sie Folgendes ein:
sudo apt-get install scrub
scrub unterstützt viele verschiedene Arten von Schrubbmustern
Available patterns are:
nnsa 3-pass NNSA NAP-14.1-C
dod 3-pass DoD 5220.22-M
bsi 9-pass BSI
usarmy 3-pass US Army AR380-19
random 1-pass One Random Pass
random2 2-pass Two Random Passes
schneier 7-pass Bruce Schneier Algorithm
pfitzner7 7-pass Roy Pfitzner 7-random-pass method
pfitzner33 33-pass Roy Pfitzner 33-random-pass method
gutmann 35-pass Gutmann
fastold 4-pass pre v1.7 scrub (skip random)
old 5-pass pre v1.7 scrub
dirent 6-pass dirent
fillzero 1-pass Quick Fill with 0x00
fillff 1-pass Quick Fill with 0xff
custom 1-pass custom="string" 16b max, use escapes \xnn, \nnn, \\
Stellen Sie scrubzum Befüllen des Laufwerks zeroszunächst sicher, dass das Laufwerk nicht montiert ist. Führen Sie dann die folgende Zeile aus ( -pbedeutet zu verwendendes Muster):
sudo scrub -p fillzero /dev/sdX
dann solltest du so etwas sehen:
scrub: using Quick Fill with 0x00 patterns
scrub: please verify that device size below is correct!
scrub: scrubbing /dev/sdh 31260704768 bytes (~29GB)
scrub: 0x00 |..... |
Einige der zum Schrubben verwendeten Muster sollten einen verifyDurchgang haben, um sicherzustellen, dass das Schrubben bestanden wurde.
Wenn Sie möchten, können Sie die hexdump(wie in der Antwort von Byte Commander) oder eine der anderen Antworten zur Überprüfung am Ende hinzufügen .
Hoffe das hilft!
Verwenden cmp(danke an muru, der auf die Albernheit der Verwendung einer Pfeife hingewiesen hat):
sudo cmp /dev/zero /dev/sdX
Wenn Sie eine Ausgabe wie diese erhalten:
cmp: EOF on /dev/sdX
Das Laufwerk ist mit Null gefüllt.
% dd if=/dev/zero of=foo iflag=fullblock bs=1M count=1 && sync
1+0 records in
1+0 records out
1048576 bytes (1,0 MB) copied, 0,00226603 s, 463 MB/s
% cmp /dev/zero foo
cmp: EOF on foo
/dev/zerodirekt für verwenden cmp, denke ich.
dd!
Mein Vorschlag wäre hexdump. Es zeigt den Inhalt einer Datei oder eines Geräts im hexadezimalen Format als Zeilen mit 16 Byte an. Wenn jedoch zwei aufeinanderfolgende Zeilen gleich sind, werden sie weggelassen.
Hier ist eine Beispielausgabe der 512-MB-Datei, virtualdevicedie nur im aktuellen Verzeichnis meiner Festplatte mit Nullen gefüllt ist. Die Spalte ganz links ist der Versatz der Zeile in hexadezimaler Schreibweise. Die folgenden 8 Spalten sind die tatsächlichen Daten, gruppiert in zwei Bytes (4 hexadezimale Zeichen):
$ hexdump ./virtualdevice
0000000 0000 0000 0000 0000 0000 0000 0000 0000
*
20000000
Ich habe mir die Mühe gemacht und meine Lösung anhand der tatsächlichen Laufzeit und der CPU-Zeit für die beschriebene Beispieldatei (512 MB, die nur binäre Nullen enthält und sich auf der Festplatte befindet) mit den anderen verglichen.
Ich habe jede Lösung mit dem timeBefehl zweimal mit frisch geleertem Festplatten-Cache und zweimal mit der bereits zwischengespeicherten Datei gemessen . Die Zeitnamen entsprechen denen des timeBefehls, und die zusätzliche Zeile CPUist nur die Summe der USER+ SYSZeiten. Dies kann die REALZeit überschreiten, da ich eine Dual-Core-Maschine verwende.
Für die meisten Menschen sind die interessanten Zahlen REAL(Zeit von Anfang bis Ende, wie mit einer Stoppuhr gemessen. Dies enthält auch die E / A-Wartezeit und die CPU-Zeit anderer Prozesse) und CPU(CPU-Zeit, die tatsächlich vom Befehl belegt wird).
Zusammenfassung:
Die beste Leistung hat murus optimierte zweite Version ( grep -zq . DEVICE), die unglaublich wenig CPU-Verarbeitungszeit benötigt.
Rang 2 cmp /dev/zero DEVICE( kos 'optimierte Lösung) und meine eigene Lösung hexdump DEVICE. Es gibt fast keinen Unterschied zwischen ihnen. Das Weiterleiten
der Daten von ddnach cmp( dd if=/dev/zero | cmp - DEVICE- kos 'nicht optimierte Lösung) ist sehr ineffizient. Das Weiterleiten scheint viel Verarbeitungszeit zu verbrauchen.
Verwenden ddund grepzeigt die mit Abstand schlechteste Leistung der getesteten Befehle.
Fazit:
Obwohl der kritischste Teil solcher Vorgänge die E / A-Zugriffszeit ist, gibt es signifikante Unterschiede in der Verarbeitungsgeschwindigkeit und Effizienz der getesteten Ansätze.
Wenn Sie sehr ungeduldig sind, verwenden Sie die zweite Version von murus Antwort ( grep -zq . DEVICE)!
Sie können aber auch entweder die zweite Version von kos 'answer ( cmp /dev/zero DEVICE) oder my own ( hexdump device) verwenden, da sie fast genauso gut abschneiden.
Mein Ansatz hat jedoch den Vorteil, dass Sie den Dateiinhalt sofort sehen und schätzen können, wie viele Bytes von Null abweichen und wo sie sich befinden. Wenn Sie jedoch viele abwechselnde Daten haben, wird die Ausgabe groß und verlangsamt sich wahrscheinlich.
Was Sie auf jeden Fall vermeiden sollten, ist die Verwendung ddund Rohre. Die Leistung von ddkönnte wahrscheinlich durch Einstellen einer geeigneten Puffergröße verbessert werden, aber warum auf komplizierte Weise?
Bitte beachten Sie auch erneut, dass der Test für eine Datei auf meiner Festplatte anstelle eines tatsächlichen Geräts durchgeführt wurde. Auch die Datei enthielt nur Nullen. Beides beeinflusst die Leistungen.
Hier sind die detaillierten Ergebnisse:
hexdump ./virtualdevice (meine eigene Lösung):
| Uncached: | Cached:
Time: | Run 1: Run 2: | Run 1: Run 2:
--------+-------------------+------------------
REAL | 7.689s 8.668s | 1.868s 1.930s
USER | 1.816s 1.720s | 1.572s 1.696s
SYS | 0.408s 0.504s | 0.276s 0.220s
CPU | 2.224s 2.224s | 1.848s 1.916s
dd if=./virtualdevice | grep -zq . && echo non zero( Murus nicht optimierte Lösung):
| Uncached: | Cached:
Time: | Run 1: Run 2: | Run 1: Run 2:
--------+-------------------+------------------
REAL | 9.434s 11.004s | 8.802s 9.266s
USER | 2.264s 2.364s | 2.480s 2.528s
SYS | 12.876s 12.972s | 12.676s 13.300s
CPU | 15.140s 15.336s | 15.156s 15.828s
grep -zq . ./virtualdevice && echo non zero( Murus optimierte Lösung):
| Uncached: | Cached:
Time: | Run 1: Run 2: | Run 1: Run 2:
--------+-------------------+------------------
REAL | 8.763s 6.485s | 0.770s 0.833s
USER | 0.644s 0.612s | 0.528s 0.544s
SYS | 0.440s 0.476s | 0.236s 0.264s
CPU | 1.084s 1.088s | 0.764s 0.808s
dd if=/dev/zero | cmp - ./virtualdevice( kos 'Lösung nicht optimiert):
| Uncached: | Cached:
Time: | Run 1: Run 2: | Run 1: Run 2:
--------+-------------------+------------------
REAL | 7.678s 6.539s | 3.151s 3.147s
USER | 2.348s 2.228s | 2.164s 2.324s
SYS | 3.672s 3.852s | 3.792s 3.516s
CPU | 6.020s 6.080s | 5.956s 5.840s
cmp /dev/zero ./virtualdevice( kos 'Lösung optimiert):
| Uncached: | Cached:
Time: | Run 1: Run 2: | Run 1: Run 2:
--------+-------------------+------------------
REAL | 6.340s 9.183s | 1.660s 1.660s
USER | 1.356s 1.384s | 1.216s 1.288s
SYS | 0.640s 0.596s | 0.428s 0.360s
CPU | 1.996s 1.980s | 1.644s 1.648s
Verwendete Befehle:
Für alle vier Tests habe ich das folgende Verfahren zweimal ausgeführt , um Ungenauigkeiten zu reduzieren, und <COMMAND>durch den genauen Befehl aus der Überschrift jeder Tabelle ersetzt.
Lassen Sie den Kernel alle Festplatten-Caches löschen:
sync && echo 3 | sudo tee /proc/sys/vm/drop_caches
Beim ersten zeitgesteuerten Ausführen (nicht zwischengespeichert) wird die Datei währenddessen in den Cache geladen:
time <COMMAND>
Zweiter zeitgesteuerter Lauf (zwischengespeichert). Diesmal werden die meisten Daten aus dem Festplatten-Cache im RAM entnommen, daher ist dies viel schneller als beim direkten Zugriff auf die Festplatte:
time <COMMAND>
ddvs ohne ddsollte wahrscheinlich auch gemacht werden grep. Veröffentlichen Sie auch den Code, mit dem Sie dies getestet haben.
hexdump? Es wird die erste Zeile mit 16 Bytes als Hexadezimalzahl gedruckt und dann [...] gedruckt und jede nachfolgende Zeile übersprungen, die der vorherigen entspricht.