null ein großes Blockgerät mit parallelisiertem dd

1234
palmbardier

Wir haben ein 60-Terabyte-Blockgerät, das wir mit dd auf Null setzen wollen. Kann diese Operation parallelisiert werden, um die benötigte Zeit zu reduzieren?

Ich habe versucht, den folgenden Befehl auszuführen, aber das ist nicht das, wonach ich suche:

seq 1 5 | parallel dd if=/dev/zero of=/dev/mapper/mydevice{} bs=10M count=10
1
Ist es ein einzelnes physisches Gerät? HDD oder SDD? Paul vor 8 Jahren 0
Wenn es sich um eine einzelne Festplatte handelt (was aufgrund der Größe vermutlich nicht der Fall ist), wird es auch nicht schneller sein, da sich der Kopf zwischen den beiden Schreibpositionen bewegen muss. Wenn es sich um ein MD-Array handelt, können Sie das Array zerstören und dd auf den verschiedenen Festplatten parallel ausführen. Wenn es sich um eine SAN-Festplatte oder ähnliches handelt, haben Sie, glaube ich, kein Glück, es sei denn, Sie verwenden Tools des SAN-Anbieters. Sig-IO vor 8 Jahren 0
Es ist ein MD-Array, aber wir möchten das Array nicht zerstören. Wir haben LVM und LUKS zusätzlich zum Linux-Software-RAID-Array. Wir wollen Blockdaten mit Nullen zuordnen (http://www.cyberciti.biz/hardware/howto-linux-hard-disk-encryption-with-luks-cryptsetup-command/), um sicherzustellen, dass die Außenwelt sehen wird dies als Zufallsdaten, dh Schutz vor Offenlegung von Nutzungsmustern. palmbardier vor 8 Jahren 0

2 Antworten auf die Frage

1
Ole Tange 
seq 0 600000 | parallel dd if=/dev/zero of=/dev/mapper/my60device bs=10M count=10 seek={}0

Sie verwenden bereits, if, of, bs, and countalso gehe ich davon aus, dass Sie wissen, was sie tun.

seeksucht nBlöcke in der Ausgabedatei, bevor Sie das ausführen dd.

Sie schreiben nicht, wie das 60-TB-Gerät physisch auf Spindeln angeordnet ist. Das kann große Auswirkungen haben. Das könnte also schneller sein:

seq 0 60000 | parallel --shuf dd if=/dev/zero of=/dev/mapper/my60device bs=10M count=100 seek={}00

Es schreibt 1 GB-Blöcke und mischt die Ausführung neu, was sich je nach physischem Layout beschleunigen oder verlangsamen kann.

Können Sie Ihre Antwort erweitern, um die Parameter zu erklären? Vielen Dank. fixer1234 vor 8 Jahren 0
Vielen Dank! Ich habe versucht --skip anstelle von --seek zu verwenden. Ersteres wirkt auf den Eingang, letzteres auf den Ausgang. D'hoi! palmbardier vor 8 Jahren 0
So wie das 60-Terabyte-Blockgerät physisch auf Spindeln angeordnet ist: 12 SATA-Laufwerke in einer 6-Gbit / s-SAS-Backplane mit Software-Linux-RAID5 im Vordergrund. palmbardier vor 8 Jahren 0
Dann hilft es wahrscheinlich nicht, die Ausgabe an das Gerät zu parallelisieren: Wenn Sie Block 1 und Block n-1 gleichzeitig schreiben, bewirken beide, dass alle Laufwerke aktiv sind = nicht gut. Wenn Sie also können, brechen Sie den Raid, dd auf jedem Gerät separat (parallel -j0 dd, wenn = / dev / zero von = {} bs = 1M ::: / dev / sd ...) und erstellen Sie danach die Überfall Ole Tange vor 8 Jahren 0
0
user474521

Wenn der zugrunde liegende Gerätetreiber nicht die gleichzeitige Planung von zwei E / A-Vorgängen durch bizare Dinge unterstützt ioctl, können Sie nicht explizit parallele E / A-Vorgänge an ein Gerät ausgeben.

dd ist das ohnehin das falsche Werkzeug, da es durch das sequentielle Schreiben von Daten in eine Datei oder ein Blockgerät funktioniert. Am besten, Sie können eine große Blockgröße angeben, die es dem Betriebssystem ermöglicht, den sequenziellen Zugriff besser zu optimieren - was das System verbessert Geschwindigkeit von Dingen wie das Schreiben auf ein Band.

Zwei ddauf einem einzigen Blockgerät zu drehen, ändert nichts an der Tatsache, dass die meisten E / A - Geräte, insbesondere Dinge, die wie Laufwerke aussehen, wirklich nur eine einzige Sache oder eine kleine Warteschlange auf einmal ausführen können - und jede Optimierung (d. H NCQ) wird auf Gerätetreiberebene ausgeführt.

Ja, wir haben in der Vergangenheit Leistungstests mit großen Arrays mit / ohne NCQ durchgeführt, jedoch mit einem anderen Hardware-RAID-Controller und ohne LUKS-Verschlüsselung. Das letzte Mal, als wir ein 22 Terabyte LUKS-Array auf Null gestellt haben, hat es ungefähr 8 Stunden gedauert. Ich werde den Vorschlag von @ OleTange ausprobieren und sehen, ob wir mit einem 60-Terabyte-Array mehr als 21 Stunden erreichen können. palmbardier vor 8 Jahren 0

Verwandte Probleme