[solved] Mittels 'pv' den Fortschritt in Logdatei schreiben

[pangu]

Hi @ll,

folgender Befehl:

Code: Alles auswählen

dd if=/dev/sda | pv -s 2000G | dd of=/dev/sdb

gibt folgendes aus (sofern pv auf dem System installiert ist) --> Es wird auf der Standardausgabe ein Fortschrittsbalken angezeigt, der ungefähr so aussieht:

110MB 0:00:04 [27,4MB/s] [> ] 0% ETA 20:37:29

Es wird angezeigt wieviel Daten bereits kopiert wurden (hier 110MB), wieviel Zeit bereits verstrichen ist (hier 04 Sekunden), wie hoch die Transferrate ist (hier 27,4 MB/sec), wieviel Prozent abgeschlossen sind bis zum Ende (hier 0%), und die voraussichtliche Dauer bis zur Fertigstellung (hier 20 Stunden, 37min und 29 Sekunden).

Diese Anzeige wird kontinuierlich auf der Ausgabe-tty angezeigt. Ich würde aber gerne in eine Logdatei namens "sicherung_aktiv.monitor" reinschreiben, so daß ich bei Bedarf in diese Datei reinschauen kann, um nachzusehen wie weit 'dd' eigentlich ist. Wie mache ich das aber? "pv" selbst bietet keine solche Option für ein Logfile an. Wie macht man das am Besten eurer Meinung nach?

Freue mich auf eure Tips und sag schonmal danke.

[uname]

Auf die dauerhafte Ausgabe würde ich verzichten. Also Aufruf von dd ohne irgendwelche Umleitungen.


Und wenn man doch mal wissen will wie weit der Kopiervorgang ist in einem anderen Terminal / screen - tmux - Terminal:

Code: Alles auswählen

kill -SIGUSR1 Prozess-ID-von-dd

[pangu]

das mit dem USR1 Signal kenne ich, bringt mich aber nicht wirklich weiter. Das "dd" Kommando wird mittels eines cronjobs initiiert. Wenn ich nun an einem anderen Terminal (zb mittels ssh eingeloggtem User) das USR1 Signal auf den laufenden DD-Prozesse sende, dann kommt die Antwort auf der tty ausgespuckt, an welcher dd läuft.

Ich möchte, daß -sofern dd momentan aktiv ist- eine Log- oder Flagdatei geschrieben wird. Und darin soll der Fortschritt angezeigt werden, und zwar würde ich das schon gerne so mit Prozent und ETA haben wollen ,wie es auch pv ausspuckt.

[Cae]

Code: Alles auswählen

       -f, --force
              Force  output.   Normally, pv will not output any visual display
              if standard error is not a terminal.  This option forces  it  to
              do so.

Saehe dann so aus:

Code: Alles auswählen

$ t=$(mktemp)
$ tail -f $t &
[1] 26737
$ pv -f </dev/zero >/dev/null 2>$t
^C.6GB 0:00:02 [9.85GB/s] [ <=>                                                ]
$ kill %1
$ rm $t
[1]+  Terminated              tail -f $t
$ t=
$ 

(und man erkennt auch die bescheuerte Eigenschaft von pv, dass versehentlich oder absichtlich eingegebene Zeichen die Anzeige Gesamtmenge ueberschreiben...)

Beachte, dass da Steuerzeichen drin sind; bei jedem Anschauen des Status wird fuer jede "geloggte" Sekunde eine Zeile auf's Terminal geschrieben und die hinterher wieder geloescht. Dagegen wuerde tail -1 $t helfen. Man sollte vielleicht das Log alle paar Stunden zuruecksetzen; es wird ja sofort der neue Fortschrittsbalken hineingeschrieben.

Gruss Cae

[pangu]

Hi Cae,

danke dir. Werd mal damit herumexperimentieren. Vielleicht lös ich das ja auch anders, mal schauen ... danke auf jeden Fall euch Allen.

[uname]

das mit dem USR1 Signal kenne ich, bringt mich aber nicht wirklich weiter. Das "dd" Kommando wird mittels eines cronjobs initiiert. Wenn ich nun an einem anderen Terminal (zb mittels ssh eingeloggtem User) das USR1 Signal auf den laufenden DD-Prozesse sende, dann kommt die Antwort auf der tty ausgespuckt, an welcher dd läuft.

Hatte ich glatt verdrängt. Aber vielleicht kann man die Ausgabe zuvor irgendwie umleiten. Du könntest mal per CRON den dd-Befehl laufen lassen und z.B. mit lsof schauen welches tty wirklich genutzt würde sofern es überhaupt eins gibt. wie man das dann ausliest weiß ich leider auch nicht. Könnte aber sein, dass du dann zwei (virtuelle) Terminals benötigst.

[detix]

Sollte denn nicht einfach das reichen:

Code: Alles auswählen

(pv -f /dev/sda1 | dd of=/dev/null) >>/tmp/sicherung_aktiv.monitor 2>&1

Deinen Befehl mochte ich hier nicht nachvollziehen,
also zum Testen sda1 nach /dev/null umgelenkt, der Inhalt der Temp-Datei sieht (gekürzt) so aus:

Code: Alles auswählen

55,1MB 0:00:01 [55,1MB/s] [>                                   ]  0% ETA 0:04:18
 102MB 0:00:02 [47,3MB/s] [>                                   ]  0% ETA 0:04:37
 147MB 0:00:03 [44,2MB/s] [>                                   ]  1% ETA 0:04:49
6,99GB 0:02:08 [56,7MB/s] [=================>                  ] 50% ETA 0:02:07
13,9GB 0:04:15 [58,2MB/s] [==================================> ] 99% ETA 0:00:00
  14GB 0:04:15 [55,9MB/s] [==================================>] 100%            
29286432+0 Datensätze ein
29286432+0 Datensätze aus
14994653184 Bytes (15 GB) kopiert, 255,875 s, 58,6 MB/s

Die erste Schätzung von pv lag garnicht mal so daneben...

[pangu]

Was meinst du mit nachvollziehen? Du meintest wohl eher "nachmachen" oder nicht?

Wenn du statt

Code: Alles auswählen

... >>/tmp/sicherung_aktiv.monitor

nun

Code: Alles auswählen

>/tmp/sicherung_aktiv.monitor

verwendest, dann müßte ja immer nur eine einzige Zeile zu sehen sein in der sicherung_aktiv.monitor, oder nicht?

[detix]

Ich weiß jetzt nicht was du meinst.
Mit "nachvollziehen" meine ich das kopieren von sda nach sdb (aus dem ersten Post),
das geht hier nicht in Ermangelung an sdb.

[Cae]

Wenn du statt

Code: Alles auswählen

... >>/tmp/sicherung_aktiv.monitor

nun

Code: Alles auswählen

>/tmp/sicherung_aktiv.monitor

verwendest, dann müßte ja immer nur eine einzige Zeile zu sehen sein in der sicherung_aktiv.monitor, oder nicht?

Nein, das betrifft nur das Oeffenen der Datei. Es wird grundsaetzlich der gesamte Output angehaengt, aber bei > wird die Dateigroesse zuvor auf Null gesetzt. Z.B.:

Code: Alles auswählen

$ seq 2 >>/tmp/foo
$ seq 3 >>/tmp/foo
$ cat /tmp/foo
1
2
1
2
3
$ rm /tmp/foo
$ seq 2 >/tmp/foo
$ seq 3 >/tmp/foo
$ cat /tmp/foo
1
2
3
$ 

Beim den >> wird immer angehaengt, am Ende sind's fuenf Zeilen, bei > wird dagegen der zweizeilige Output verworfen und durch den dreizeiligen ersetzt.

Gruss Cae

[ThorstenS]

Ich sichere meine VMs auch seit Jahren „raw“. Anfangs mit dd, dann mit pv. Daher einige Anmerkungen zum unnützen Gebrauch von dd

Wenn schon dd, dann bitte mit bs=2M - dann rennt die Kiste auch:
dd if=/dev/sda bs=2M |…

Anstelle von dd kannst du auch direkt cat benutzen - das steigert den Durchsatz nochmal.
cat /dev/sda |…

Aber anstelle des zwoten dd lass pv den Job tun:
dd…| pv … > /dev/sdb.

Oder die beste Variante von allen:Lass pv den Job komplett übernehmen (mein Vorgehen):
pv -s250GB -cN "sda" /dev/sda > /mnt/backup/${VMid:-default}/VollSicherung_sda-`date -I`.img
(bzw. auf das andere blockdevice)

Zur eigentlichen Frage hin gibt dir das hier vllt. eine Hilfe: http://unix.stackexchange.com/questions ... named-pipe

[pangu]

Danke Thorsten. Du meinst also immer blocksize von 2Megabyte verwenden beim dd-kopieren ??? Ist das definitiv schneller oder wären sogar kleinere oder größere Blockgrößen empfehlenswerter für ext4 ?

und wieso ist cat schneller als dd und wieso wird aber immer von dd geredet bei solchen Zwecken? muss doch sicherlich irgendwelche caveats haben wenn man cat nutzt, oder nicht? Sonst würden ja sämtliche Tutorial da draußen mit "cat" Beispiele zeigen, um festplatten zu klonen, stattdessen ist aber immer von dd die Rede.

[ThorstenS]

Mach dir selbst mal ein paar benchmarks und du wirst schnell sehen, dass du mit 2MegaByte besser dran bist als mit den default 512byte.

pv wird zwar schon seit 11 Jahren entwickelt, aber ist lange Zeit nicht im Fokus der $MASSE gewesen. Die meisten sind Gewohnheitstiere und nutzen das, was sie kennen. pv setzt sich aber zum Glück immer weiter durch und das alterwürdige dd (welches nur nebenbei von blockdevicen liest, das kann ja sehr viel mehr als du wahrscheinlich weist/nutzt) wird dann für diesen Zweck irgendwann aussterben.

Dem Herrn Koffler wirst du sicherlich glauben, wenn es um cat anstelle von dd geht, lies mal den Artikel hier: http://kofler.info/blog/186/126/Schnell ... -mit-lzop/
Unter Unix/Linux gibt es einen Grundsatz: Alles ist eine Datei. Und damit kann cat sehr gut umgehen. Es funktioniert wirklich.

Generell kann ich dir nur empfehlen selbst zu testen und manpages zu lesen (am besten die englischen mit LANG=C man sed ).
Da ändert sich tatsächlich im Laufe der Jahre etwas.
Ich war seinerzeit total aus dem Häuschen, dass sed in Version 4.0 plötzlich mittels -i inline-replacements kennt. Man musste nicht mehr über eine temporäre Datei gehen. Aber durchgesetzt hat sich das in den Foren erst Jahre später.
Genauso dass find den Schalter -delete hat, welches ein nachgeschaltetes | xargs -0 rm oder -exec rm {} + überflüssig macht und keine Probleme mit Leer/Sonderzeichen im Dateinamen hat. Das alles findest du nur, wenn du regelmäßig mal in die manpage schaust, oder div. blogs von Entwicklern liest.

[pangu]

also das mit -delete im find-Befehl ist jetzt nebenbei erwähnt wirklich TOP! Hatte ich auch nicht gewußt. Danke für diesen Tip!!

und danke für Links, werde mir das in Ruhe zu Gemüte ziehen und ausprobieren. Vielen herzlichen Dank!

[Cae]

Also zumindest auf meiner Maschine ist das Lesen in Blockgroessen von 128 oder 256 MB optimal fuer's RAM:

Code: Alles auswählen

#!/bin/bash
# MIT License, author <cae@debianforum.de>

export bs=128;
while [ 100000000 -gt $bs ]; do
	count=$((8589934592 / $bs)); # 8 GiB
	dd if=/dev/zero bs=$bs count=$count of=/dev/null 2>&1 \
	| awk '/\/s$/ { print "'$bs', '$count'x\t" $(NF-1) FS $NF }';
	bs=$((2 * bs));
done

exit $?

sample output:
:r!./memspeed
128, 67108864x	510 MB/s
256, 33554432x	965 MB/s
512, 16777216x	1.8 GB/s
1024, 8388608x	3.2 GB/s
2048, 4194304x	5.2 GB/s
4096, 2097152x	7.5 GB/s
8192, 1048576x	9.5 GB/s
16384, 524288x	10.9 GB/s
32768, 262144x	11.8 GB/s
65536, 131072x	11.8 GB/s
131072, 65536x	12.3 GB/s
262144, 32768x	12.3 GB/s
524288, 16384x	11.5 GB/s
1048576, 8192x	9.7 GB/s
2097152, 4096x	9.7 GB/s
4194304, 2048x	9.4 GB/s
8388608, 1024x	4.9 GB/s
16777216, 512x	4.7 GB/s
33554432, 256x	4.6 GB/s
67108864, 128x	4.5 GB/s

Das duerfte nicht eins zu eins fuer Peripherie gelten, aber das Prinzip ist auch da gleich: Zu kleine und zu grosse Blockgroesse ist doof, irgendwo dazwischen gibt's ein Optimum. Normale Festplatten im Bereich von >500 GB haben meist 64 MB Cache, das ist auch der Wert, mit dem ich standardmaessig fahre.

cat(1) duerfte wesentlich kleinere Blockgroessen verwenden; ich hab' hier gerade eins aus coreutils-8.13 herumfliegen, das nimmt entweder die Blockgroesse von Ein- oder Ausgangsdatei, je nachdem welche groesser ist. Also in der Groessenordnung um 8kB. Fuer mein RAM waer's nicht optimal, 12.3 GB/s mit 128 MB Blockgroesse ist einfach mehr als 9.5 GB/s. Allerdings ist jegliche normalsterbliche Peripherie langsamer als das.

dd(1) ist halt naheliegender, weil's so Features wie seek= oder skip= oder eben die Blockgroesse/-Anzahl bei cat(1) nicht einzustellen gibt.

Gruss Cae

[pangu]

Hi Cae,

könnte ich dein Skript genauso auch auf meiner Maschine verwenden, um die optimale BS zu ermitteln?

[Cae]

Hi Cae,

könnte ich dein Skript genauso auch auf meiner Maschine verwenden, um die optimale BS zu ermitteln?

Ja, sogar genau so. Die Ausgabe unten wird durch das exit $? nie aufgerufen, so aenlich wie bei Perl das __END__.

Gruss Cae

[pangu]

Also zumindest auf meiner Maschine ist das Lesen in Blockgroessen von 128 oder 256 MB optimal fuer's RAM:

Code: Alles auswählen

[...]
131072, 65536x	12.3 GB/s
262144, 32768x	12.3 GB/s
[...]
[/quote]

Megabyte?? Ich glaub wohl eher du meintest 128 Kilobyteblöcke, bzw. 256 Kb, oder nicht?? Bitte berichtige mich falls ich falsch liege, aber wenn man dem dd keine Einheit mitteilt, dann ist doch die Einheit 'bytes'.

bs=1 (Blockgröße 1 Byte)
bs=1K (Blockgröße 1Kilobyte)
bs=1M (Blockgröße 1Megabyte)

Oder änderst du da etwas mit deinem Awk-Befehl nach der Pipe ab?? Ich hab den awk-Befehl eh nicht verstanden, was da genau gemacht wird. Deswegen hatte ich ja vorhin nochmal sicherheitshalber nachgefragt, ob ich dein Skript so bei meiner Maschine verwenden kann. War mir etwas unsicher wegen dieser awk-Zeile :p

EDIT: Ich hab jetzt dein Skript an 4 verschiedenen Hosts durchlaufen lassen, und immer erhielt ich bei [b]16K Blockgröße[/b] den besten Throughput.

[Cae]

Hups, da ist 'ne 2^10-Dimension verloren gegangen. Ja, es sind 128 bzw. 256 kB.

Gruss Cae

[pangu]

Sollte denn nicht einfach das reichen:

Code: Alles auswählen

(pv -f /dev/sda1 | dd of=/dev/null) >>/tmp/sicherung_aktiv.monitor 2>&1

also zum Testen sda1 nach /dev/null umgelenkt, der Inhalt der Temp-Datei sieht (gekürzt) so aus:

Code: Alles auswählen

55,1MB 0:00:01 [55,1MB/s] [>                                   ]  0% ETA 0:04:18
 102MB 0:00:02 [47,3MB/s] [>                                   ]  0% ETA 0:04:37
 147MB 0:00:03 [44,2MB/s] [>                                   ]  1% ETA 0:04:49
6,99GB 0:02:08 [56,7MB/s] [=================>                  ] 50% ETA 0:02:07
13,9GB 0:04:15 [58,2MB/s] [==================================> ] 99% ETA 0:00:00
  14GB 0:04:15 [55,9MB/s] [==================================>] 100%            
29286432+0 Datensätze ein
29286432+0 Datensätze aus
14994653184 Bytes (15 GB) kopiert, 255,875 s, 58,6 MB/s

Da ich das jetzt selbst austesten wollte, muss ich ja irgendwie angeben wie groß die zu kopierenden Datenmengen werden sollen. Das kann ich jedoch nur, wenn ich dd verwende und darin blocksize und count nutze. Will ja nicht warten, bis meine komplette /dev/sdx nach /dev/null kopiert wird. Also musste ich den Befehl wie folgt abändern, das Prinzip ist aber dasselbe wie bei dir, oder nicht? Ich hab ja den eigentlich Kopierprozess in Klammern gesetzt und damit in eine sub-shell:

Code: Alles auswählen

(dd if=/dev/zero bs=$bs count=$((4294967296 / $bs)) | pv -f -p -t -e -r -b -a -s 4G | dd of=/dev/null) >>output.monitor 2>&1

Damit generiere ich 4GB an Testdaten. Nun, ich habe folgendes festgestellt:

wenn ich 2>&1 ganz am Ende weglasse, dann wird zwar die output.monitor generiert, enthält aber immer 0 Bytes. Es landen keine Daten darin. Wenn ich 2>&1 verwende, dann funktioniert es (teilweise):

während der Prozess nämlich läuft und die Daten kopiert werden, dann steigt die Byte-Zahl der Datei "output.monitor" stetig an, und zwar bis zu 1701 Bytes. Währenddessen, wenn ich jedoch ein "cat output.monitor" versuche, kriege ich keine Ausgabe zurück, als ob die Datei leer wäre. Ich vermute mal, dass dort lediglich irgendwelche Art von Steuerzeichen drinlanden?

==> Erst wenn der Prozess komplett beendet ist, kann ich mir die output.monitor mit "cat output.monitor" anzeigen lassen und erhalte so eine Ausgabe:

# cat output.monitor
33554432+0 Datensätze ein [ 191MB/s] [=======================> ] 97% ETA 0:00:00
33554432+0 Datensätze aus
4GB 0:00:21 [ 191MB/s] [ 191MB/s] [=======================>] 100%
4294967296 Bytes (4,3 GB) kopiert, 21,4506 s, 200 MB/s
6816936+2117326 Datensätze ein
8388608+0 Datensätze aus
4294967296 Bytes (4,3 GB) kopiert, 21,4513 s, 200 MB/s

die output.monitor hat genau 2005 Bytes. Also irgendwie immer noch nicht das, was ich eignetlich erreichen wollte. Ich möchte in die output.monitor reinschauen können, um dne aktuellen Stand anzeigen lassen zu können. Momentan krieg ich das so aber wohl nicht gebacken.

[pangu]

Habe die Lösung!

Und zwar brauch ich den grafischen Schnickschnack mit der Fortschrittsanzeige als Balkenform gar nicht. Das generiert ja nur diese Steuercodes und anhand des Bufferings krieg ich diese Anzeigeprobleme. Habe nun einfach den Schalter -n verwendet für "numeric" Anzeige. Dann braucht man den Schalter -f nicht mehr.

Der Einzeiler sieht dann also so aus (für meinen Test):

Code: Alles auswählen

(dd if=/dev/zero bs=$bs count=$((4294967296 / $bs)) | pv -n -p -t -e -r -a -s 4G | dd of=/dev/null) >test.monitor 2>&1

und in der test.monitor wird folgender Output generiert. Die einzelnen Zeile entsprechen dem Prozentanteil, wieviel bereits abgeschlossen ist. Und wenn das bei 100 angelangt ist, kriegt man am Ende auch die Zusammenfassung mit Infos wie "übertragene Datenmenge", durchschnittlicher Durchsatz, usw...

4
9
13
18
23
27
32
37
41
46
50
55
60
64
69
74
78
83
88
92
97
33554432+0 Datensätze ein
33554432+0 Datensätze aus
4294967296 Bytes (4,3 GB) kopiert, 21,5802 s, 199 MB/s
6963036+1923266 Datensätze ein
8388608+0 Datensätze aus
4294967296 Bytes (4,3 GB) kopiert, 21,5811 s, 199 MB/s

Somit genau das was ich haben wollte. Ich kann jederzeit durch Betrachten der "test.monitor" nachschauen, wieweit der dd-Prozess ist.

EDIT: Das einzige was noch blöd ist, daß ca. 2x in der Sekunde eine neue Zeile geschrieben wird. Das bedeutet, daß im Outputfile so was drinstehen wird beim Klonen einer 2TB Platte:

0
0
0
0
0
0
0
0
0
...und nach Stunden immer noch hunderte/tausende Zeilen mit diesen Nullen
5
5
5
5
5
5
5
5
5
5
5
5
...und so weiter...

Wie könnte man das unterbinden, so daß KEINE neue Zeile verwendet wird ? Ich glaub mittels dem pv-Kommando kann man das ja nirgends einstellen, denn in der 'man' heißt es ja, dass immer eine neue Zeile geschrieben wird.

-n: Numeric output. Instead of giving a visual indication of progress, pv will give an integer percentage, one per line, on standard error, ...

könnte man da evtl. noch nachträglich awk pipen und das so irgendwie lösen?? Evtl. mit nem if- und last statement innerhalb awk?? Meillo, wo steckst du awk-Guru? *help*

[ThorstenS]

Schreib den output nach /dev/shm/monitor.unsorted und lass
periodisch ein uniq /dev/shm/monitor.unsorted > /dev/shm/monitor.sorted laufen, in diese Datei schaust du dann rein.
Achja, falls du Start und Endzeit mitloggen willst, ich mach das immer so:

Code: Alles auswählen

#!/bin/bash                                                                                                                                 
# Laufzeit eines Scripts ausgeben by ThorstenS
echo -e "Start:\v\t$(date "+%Y-%m-%d %H:%M")"
time_start=$(date +%s)

sleep 3

time_end=$(date +%s)
time_elapsed=$((time_end - time_start))
echo -e "Ende:\v\t$(date "+%Y-%m-%d %H:%M")"
echo -e "Dauer:\v\t$(( time_elapsed / 3600 ))h $(( time_elapsed %3600 / 60 ))m $(( time_elapsed % 60 ))s"

EDIT:
sed kann dir die Datei auch periodisch zurechtstutzen, laut http://www.catonmat.net/blog/sed-one-li ... art-three/ machst du dann einfach ein sed -i '$!N; /^\(.*\)\n\1$/!P; D' /dev/shm/monitor.unsorted

[detix]

Das einzige was noch blöd ist, daß ca. 2x in der Sekunde eine neue Zeile geschrieben wird.

Eigentlich wird nur jede Sekunde eine Zeile geschrieben,
du kannst pv mit dem Parameter "-i" anweisen zB nur jede Minute zu schreiben (-i 60),
wirst ja nicht im Sekundentakt in die Datei schauen,
die Anzahl der Zeilen entspräche dann sogar der Dauer in Minuten, zum Testen:

Code: Alles auswählen

(pv -n -i 60 /dev/sda | dd of=/tmp/sicherung) >>/tmp/sicherung_aktiv.monitor 2>&1
0
1
1
2
9241344+0 Datensätze ein
9241344+0 Datensätze aus
4731568128 Bytes (4,7 GB) kopiert, 241,658 s, 19,6 MB/s

Abbruch (bloß nicht durchlaufen lassen!) in der 4ten Zeile (=4 Minuten), passt auch ohne Rechnerei.

[pangu]

Danke für diese Info, würde aber trotzdem gerne wissen/lernen, wie man das Logfile so frisieren könnte, dass immer nur der letzte output (=Zahl) zu sehen ist.

[pangu]

Schreib den output nach /dev/shm/monitor.unsorted und lass
periodisch ein uniq /dev/shm/monitor.unsorted > /dev/shm/monitor.sorted laufen, in diese Datei schaust du dann rein.

was genau macht /dev/shm , warum dort hinein schreiben die Logdatei? shm ist irgendwie shared-memory, soweit so gut, aber ich verstehe nicht den Sinn. Vielleicht kannst du mich aufklären?

sed kann dir die Datei auch periodisch zurechtstutzen, laut http://www.catonmat.net/blog/sed-one-li ... art-three/ machst du dann einfach ein
sed -i '$!N; /^\(.*\)\n\1$/!P; D' /dev/shm/monitor.unsorted

Ich würde jetzt schon wirklich gerne wissen, wie ich in diesen Befehl erweitern könnte ...

Code: Alles auswählen

(dd if=/dev/zero bs=16384 count=131072 | pv -n -p -t -e -r -a -s 2G | dd of=/dev/null) 2>active_dd.monitor 

dass weiterhin active_dd.monitor verwendet wird als Logdatei, und diese eben gleich beim Beschreiben angepasst wird. Ist das denn mit awk nicht irgendwie möglich? Ich bin mir (fast) sicher, daß es mit awk klappen sollte.

evtl. kann ich auch einfachhalber einfach irgendwie sed's Einzeiler

Code: Alles auswählen

sed '$d' dateiname

nutzen? Das entfernt die letzte Zeile. Wie müsste ich das aber in den oben genannten Befehl einfügen, damit es jedesmal ausgeführt wird, wenn der pv-Befehl etwas ins logfile schreibt? Das hier würde ja nicht funktionieren...

Code: Alles auswählen

(dd if=/dev/zero bs=16384 count=131072 | pv -n -p -t -e -r -a -s 2G | dd of=/dev/null) 2>active_dd.monitor && sed '$d' active_dd.monitor

weil sed nur 1x ausgeführt werden würde.