Seltsames Verhalten beim Pipen von dd durch pv
Hallo,
ich nutze dd gerne, um Festplatten etwas zu quälen. Da hat mir die Beschreibung zum Einbinden von pv als Fortschrittsanzeige sehr gefallen.
Als ich testweise 1 GB in 1MB-Blöcken (bs=1M count=1024) von /dev/urandom nach /dev/null verschoben habe, musste ich eine unerfreuliche Entdeckung machen: Der Vorgang beendete sich "sauber" nach 128MB. 😮 Ohne pv lief es richtig durch und mit verendete es reproduzierbar bei 128MB.
thosch@xxx:~$ dd if=/dev/urandom bs=1M count=1024 | pv -s 1G | dd of=/dev/null bs=1M count=1024 0+1024 Datensätze einB/s] [===> ] 12% ETA 0:04:18 0+1024 Datensätze aus 134217728 Bytes (134 MB) kopiert, 36,7334 s, 3,7 MB/s 128MB 0:00:36 [3,46MB/s] [===> ] 12%
Ein Crosscheck unter what-ever-Linux auf meinem QNAP-NAS und Mac OS X (dort schon bei 64MB) ergaben ähnliche Ergebnisse. Es muss also an pv liegen.
Als ich die Größenparameter (bs=1M count=1024) auf der Zielseite der Pipe wegließ, lief es sauber durch. Auf allen drei Systemen.
thosch@xxx:~$ dd if=/dev/urandom bs=1M count=1024 | pv -s 1G | dd of=/dev/null 1GB 0:04:58 [3,43MB/s] [=================================>] 100% 2097152+0 Datensätze ein 2097152+0 Datensätze aus 1073741824 Bytes (1,1 GB) kopiert, 298,876 s, 3,6 MB/s 1024+0 Datensätze ein 1024+0 Datensätze aus 1073741824 Bytes (1,1 GB) kopiert, 298,876 s, 3,6 MB/s
Kann es sein, dass diese Parameter auf der Zielseite unter bestimmten Umständen dazu führen, dass Vorgang zu früh "sauber" beendet wird? Der Sinn der Parameter auf dieser Seite hat sich mir sowieso nicht eröffnet, weil das Ziel einfach so viel schluckt, wie die Quelle schickt.
Wie seht Ihr das? Sollte man diesen Code-Schnipsel im Artikel anpassen?
Gruß
Thomas