[gelöst] Kopieren auf USB-Stick, Fortschrittsanzeige unrealistisch

[geoliver2104]

Hallo,
Ich verwende Debian 11 stable (5.10.0-14-amd64).
habe kürzlich eine große Datei ( 3.4 Gb ) auf einen USB-2.0 Stick kopiert.
Das ging laut Fortschrittsanzeige binnen weniger Sekunden.
Also eigentlich unmöglich schnell.
Bin dem auf der Kommandozeile nachgegangen und hab festgestellt, dass schon der Befehl

Code: Alles auswählen

cp big.file /media/user

nach kurzer Zeit, den Shell-Prompt wieder freigibt obwohl im Hintergrund sicher noch immer kopiert wird.
Weil ein anschließendes

Code: Alles auswählen

umount /media/user

dauert dann wirklich solange, wie es der Übertragungsgeschwindigkeit entspricht.
Ich würde aber gern sehen, wie lange es noch dauern wird, bis ich den Stick abziehen kann.
Hat sicher irgendwas mit Puffern zu tun .
Habt ihr einen Tip ?

[Strunz_1975]

Hallo,

propier doch mal enweder:

mc (=Midnight Commander)

oder:

rsync -a --progress big.file /media/user/

cu
Strunz_1975

[Livingston]

Am Ende ein sync hinterher, was die Puffer lehrt:

Code: Alles auswählen

cp big.file /media/user && sync

Sobald der Cursor wieder blinkt, ist alles erledigt.

EDIT: Nachtrag zum Hintergrund
Egal, womit Du kopierst: Es gibt in der Regel 2 Puffer. Der eine dient der Übertragung vom Userprogramm zum Betriebssystem, der andere vom Betriebssystem zur Hardware. Ein Befehl wie cp, mc oder rsync zeigt nur an, wann der erste Teilschritt erledigt ist und verkündet dann Vollzug.
Sichergehen, dass alles erledigt ist, kannst Du nur nach einem expliziten sync oder - wie Du oben beschrieben hast - nach einem impliziten sync durch umount oder ähnliches.

[DeletedUserReAsG]

Man kann ein Dateisystem mit der Option sync einhängen – dann wird’s direkt geschrieben. Wird entsprechend elendig langsam, und ist insbesondere für SSDs nicht empfehlenswert.

[GregorS]

... ist insbesondere für SSDs nicht empfehlenswert.

Wieso denn das?

Gruß

Gregor

[DeletedUserReAsG]

Wieso denn das?

Weil bei direkten Wegschreiben ein interner Speicherblock mehrfach gelesen, geändert und zurückgeschrieben wird. Das ist für Flash-Medien so ziemlich das Schlechteste, was man machen kann – eine entsprechende Warnung steht auch in der Manpage.

[geoliver2104]

Danke für die Antworten !
kopieren mit dem Midnight Commander dauert genauso kurz wie mit dem Befehl cp.
das mit

Code: Alles auswählen

cp big.file /media/user && sync

versteh ich auch, nur hab ich da keine Fortschrittsanzeige und weiss nicht wann das Ende des Kopiervorgangs zu erwarten ist.
Interessant klingt das Einhängen mit der Option sync für externe USB-Speicher.
Lässt sich die sync-Option auch mit udisksctl realisieren ?
Das wär mein bevorzugter Weg,

[MSfree]

Code: Alles auswählen

cp big.file /media/user && sync

versteh ich auch, nur hab ich da keine Fortschrittsanzeig

Kopieraktionen die auf ein Dateisystem erfolgen, werden vom Kernel gecacht. Die Anwedungsprogramme "sehen" grundsätzlich nur den Vorgang, bis die Daten vom Kernel logisch ins Dateisystem einsortiert wurden, die Rückmeldung, wenn die Daten physikalisch auf dem Datenträger gelandet sind, gibt es nicht.

Mit sync kannst du zwar erzwingen, daß alle gecachten Daten auf den Datenträgern landen, was übrigens auch die Daten einschließt, die du gar nicht syncen wolltest. Aber hierfür gibt es nunmal keine Rückmeldung vom Kernel, wann der Vorgang fertig ist. Folglich ist eine Fortschrittsanzeige hier völlig unmöglich. Es dauert halt solange wie es dauert.

Nur, wenn du das betreffende Dateisystem mit der Option "sync" mountest, verwendet der Kernel keinen Cache für dieses Dateisystem. Anwendungsprogramme sehen dann direkt die Schreibgeschwindigkeit auf das Speichermedium und nicht die Schreibgeschwindigkeit in den Cache.

Ja, das ist für ungeduldige Naturen unbefriedigend. Es ist aber wie es ist, Rückmeldung und Fortschritt gibt es nicht.

[heisenberg]

Wenn sich der Dirty(Dirty=nicht auf den Datenträger geschriebene Daten) Zähler gegen Null bewegt ist der Kopiervorgang abgeschlossen:

Code: Alles auswählen

watch -d grep -e Dirty: -e Writeback: /proc/meminfo

Mehr dazu unter...

https://unix.stackexchange.com/question ... -operation

[geoliver2104]

mounten mit sync Option ist auch keine Lösung.
Da hat man zb. im MidnightCommander eine Fortschrittsanzeige und wenn die auf 100% ist,
kann der Stick sofort ausgehängt werden.
Das dauert dann aber ca. 3 mal solange, wie mounten ohne sync, Datei kopieren und warten auf umount.
(mit Stoppuhr gemessen)
den Tip von @heisenberg hab ich noch nicht ausprobiert.

[DeletedUserReAsG]

Das dauert dann aber ca. 3 mal solange, wie mounten ohne sync, Datei kopieren und warten auf umount.

Ist ja nicht so, dass ich nicht geschrieben hätte, dass es elendig langsam wäre. Ist auch nicht so, dass ich nicht geschrieben hätte, dass man tunlichst vermeiden sollte, das mit Flash-Speichern zu machen – weil die recht bald durchgeschrieben (vulgo: kaputt) wären.

Insofern frage ich mich nun schon ein wenig, was du dir nun davon erhofft hast – dass es bei dir nicht so wäre, wie bei allen Anderen?

[heisenberg]

Interessehalber habe ich mir - wie in dem stackexchange thread angemerkt mal /sys/block/DEVNAME/stat angeschaut. Das scheint mir aber für die Aufgabe keine relevanten Informationen beizutragen. Es folgen Details dazu.

Hier die Doku der von mir verwendeten Kernelversion dazu:
https://git.kernel.org/pub/scm/linux/ke ... =v5.10.119

Ein kleines Script, dass ich laufen lasse, während ich kopiere:

Code: Alles auswählen

#!/bin/bash

file=/sys/block/$1/stat

format="%-5s %-5s %-6s %-5s %-6s %-5s %-8s %-7s %-8s %-7s %-6s %-6s %-6s %-6s %-6s %-6s %-6s %-6s\n"
printf "$format" "rIO" "rMrg" "rSct" "rTck" "wIO" "wMrg" "wSct" "wTck" "inFlight" "ioTck" "tInQ" "disIO" "disMrg" disSct disTck flIO flticks

while :; do
        printf "$format" $(cat $file)
        sleep 1
done

Ausgabe während ich "cp debian-11.2.0-amd64-DVD-1.iso /usbstick/" ausführe:

Code: Alles auswählen

rIO   rMrg  rSct   rTck  wIO    wMrg  wSct     wTck    inFlight ioTck   tInQ   disIO  disMrg disSct disTck flIO   flticks 
1417  71    48726  2676  428625 11407 27364158 1149718 0        773704  1152930 0      0      0      0      470    536          
1417  71    48726  2676  428625 11407 27364158 1149718 0        773704  1152930 0      0      0      0      470    536          
1417  71    48726  2676  428625 11407 27364158 1149718 0        773704  1152930 0      0      0      0      470    536          
1417  71    48726  2676  429248 11407 27403638 1150910 0        774508  1154122 0      0      0      0      470    536          
1417  71    48726  2676  429488 11407 27418742 1152837 0        775544  1156049 0      0      0      0      470    536          
1417  71    48726  2676  430282 11407 27468806 1154323 0        776544  1157535 0      0      0      0      470    536          
1417  71    48726  2676  430805 11407 27501798 1155291 0        777204  1158504 0      0      0      0      470    536          
1417  71    48726  2676  431228 11467 27528430 1156902 0        778536  1160118 0      0      0      0      472    539          
1417  71    48726  2676  432025 11467 27579406 1158372 0        779548  1161588 0      0      0      0      472    539          
1417  71    48726  2676  432348 11467 27600014 1158959 0        779940  1162175 0      0      0      0      472    539          
1417  71    48726  2676  433032 11467 27643534 1161728 0        781548  1164943 0      0      0      0      472    539          
1417  71    48726  2676  433823 11467 27694030 1163207 0        782548  1166422 0      0      0      0      472    539          
1417  71    48726  2676  434026 11471 27706886 1164322 0        783548  1167538 0      0      0      0      472    539          
1417  71    48726  2676  434794 11472 27755806 1165831 0        784552  1169049 0      0      0      0      474    541          
1417  71    48726  2676  435437 11472 27796446 1167039 0        785372  1170257 0      0      0      0      474    541          
1417  71    48726  2676  435788 11472 27818582 1168441 0        786552  1171659 0      0      0      0      474    541          
1417  71    48726  2676  436589 11472 27869582 1169919 0        787556  1173137 0      0      0      0      474    541          
1417  71    48726  2676  436983 11472 27894670 1170645 0        788040  1173863 0      0      0      0      474    541          
1417  71    48726  2676  437593 11475 27933190 1172535 0        789556  1175756 0      0      0      0      476    545          
1417  71    48726  2676  438404 11475 27984774 1174020 0        790556  1177241 0      0      0      0      476    545          
1417  71    48726  2676  438610 11475 27997894 1175145 0        791560  1178367 0      0      0      0      476    545          
1417  71    48726  2676  439434 11475 28050374 1176633 0        792560  1179855 0      0      0      0      476    545          
1417  71    48726  2676  440074 11475 28091078 1177819 0        793356  1181040 0      0      0      0      476    545          
1417  71    48726  2676  440427 11484 28113342 1179987 0        794560  1183211 0      0      0      0      478    547          
1417  71    48726  2676  441255 11484 28166006 1181481 0        795564  1184705 0      0      0      0      478    547          
1417  71    48726  2676  441621 11484 28189302 1182171 0        796024  1185395 0      0      0      0      478    547          
1417  71    48726  2676  442272 11484 28230774 1184102 0        797564  1187326 0      0      0      0      478    547          
1417  71    48726  2676  443087 11484 28282622 1185575 0        798564  1188799 0      0      0      0      478    547          
1417  71    48726  2676  443297 11492 28295806 1186691 0        799568  1189917 0      0      0      0      480    549          
1417  71    48726  2676  444073 11493 28344982 1188139 0        800568  1191364 0      0      0      0      480    549          
1417  71    48726  2676  444712 11493 28385726 1189328 0        801364  1192553 0      0      0      0      480    549          
1417  71    48726  2676  445088 11493 28409726 1191499 0        802568  1194725 0      0      0      0      480    549          
1418  71    48734  2677  445864 11494 28459262 1192919 0        803572  1196146 0      0      0      0      480    549          
1418  71    48734  2677  446250 11495 28483902 1193626 0        804064  1196854 0      0      0      0      480    549          
1418  71    48734  2677  446785 11502 28517782 1196272 0        805572  1199503 0      0      0      0      482    553          
1418  71    48734  2677  447590 11504 28569174 1197765 0        806572  1200996 0      0      0      0      482    553          
1418  71    48734  2677  447799 11504 28582486 1198895 0        807576  1202126 0      0      0      0      482    553          
1418  71    48734  2677  448612 11506 28634390 1200387 0        808576  1203618 0      0      0      0      482    553          
1418  71    48734  2677  449332 11508 28680342 1201719 0        809472  1204950 0      0      0      0      482    553          
1418  71    48734  2677  449617 11512 28698438 1203735 0        810576  1206967 0      0      0      0      484    554          
1418  71    48734  2677  450413 11514 28749254 1205199 0        811580  1208432 0      0      0      0      484    554          
1418  71    48734  2677  450871 11516 28778502 1206021 0        812140  1209254 0      0      0      0      484    554          
1418  71    48734  2677  451427 11516 28814022 1208511 0        813580  1211744 0      0      0      0      484    554          
1418  71    48734  2677  452243 11518 28866110 1209977 0        814580  1213210 0      0      0      0      484    554          
1418  71    48734  2677  452455 11518 28879622 1211104 0        815584  1214337 0      0      0      0      484    554          
1418  71    48734  2677  453269 11525 28931510 1212598 0        816584  1215833 0      0      0      0      486    557          
1418  71    48734  2677  453950 11525 28974974 1213887 0        817440  1217122 0      0      0      0      486    557          
1418  71    48734  2677  454278 11525 28995902 1215965 0        818584  1219200 0      0      0      0      486    557          
1418  71    48734  2677  455102 11527 29048638 1217426 0        819588  1220661 0      0      0      0      486    557          
1418  71    48734  2677  455485 11528 29073150 1218108 0        820056  1221343 0      0      0      0      486    557          
1418  71    48734  2677  456102 11534 29112510 1219994 0        821588  1223231 0      0      0      0      488    559          
1418  71    48734  2677  456919 11534 29164798 1221434 0        822588  1224671 0      0      0      0      488    559          
1418  71    48734  2677  457144 11535 29179198 1223298 0        823592  1226535 0      0      0      0      488    559          
1418  71    48734  2677  457958 11536 29231278 1224819 0        824592  1228056 0      0      0      0      488    559          
1418  71    48734  2677  458557 11537 29269566 1225864 0        825312  1229100 0      0      0      0      488    559          
1418  71    48734  2677  459011 11543 29298494 1227410 0        826592  1230649 0      0      0      0      490    560     

[TRex]

Insofern frage ich mich nun schon ein wenig, was du dir nun davon erhofft hast – dass es bei dir nicht so wäre, wie bei allen Anderen?

Vielleicht hat ihm der Grund gefehlt, warum das langsamer ist - das hat noch keiner erklärt. Die bereits erwähnten einzelnen Aktionen werden gebündelt, das ist ein Teil. Der andere ist, dass AFAIK die Blockgröße der Speicher effizienter genutzt werden kann. Ein konkreter Beweis für die Aussage würde mich auch interessieren (so in der Art eines Logs vom Kernel, welche Datenpakete übertragen wurden, 1000 mal 1M vs ein Vielfaches an fragmentierteren Blöcken), hab ich aber leider nicht.

[DeletedUserReAsG]

Das größte Problem mit diesen Flash-Speichern ist, dass ihre interne Struktur nicht viel mit der Struktur zu tun hat, die der Controller nach außen präsentiert: die internen Blöcke sind beispielsweise meist größer, als die logische Blockgröße. Eine Eigenart von Flash ist’s, dass man nicht einfach wie bei einem alten HDD die Bits einzeln ändern kann. Wenn dort auch nur ein Bit geändert wird, muss der komplette (interne) Block gelesen, das Bit geändert und der komplette (interne) Block zurückgeschrieben werden. Das kann bedeuten, dass ein und derselbe (interne) Block ’zig mal neu geschrieben wird, wenn man den Dateisystemtreiber zwingt, jeden (logischen) Block fertigzuschreiben, bevor’s weitergeht – mit den erwartbaren Auswirkungen auf die Performance und den Verschleiß.

[heisenberg]

Hier mal ein Script als Ansatz mit dem man schauen kann, wann solche Prozesse ungefähr fertig sind:

https://codeberg.org/megabert/script-pa ... rack-dirty

Das lässt man bei dem Kopiervorgang nebenher als root normaler Benutzer laufen.

Ausgabe:

Code: Alles auswählen

# track-dirty
starting...
waiting for initial data...
Dirty Bytes sync ETA: 00:04:36                                                           
storage write process finishing...                                    

...oder wenn kein Kopierprozess läuft...

Code: Alles auswählen

starting...
no storage write process running

Suchbegriffe: Fortschrittsanzeige Progressbar USB-Stick kopieren

[MSfree]

Das lässt man bei dem Kopiervorgang nebenher als root laufen.

/proc/meminfo ist auch als normaler Nutzer lesbar. Für was sonst braucht das Skript root-Rechte?

[heisenberg]

Das lässt man bei dem Kopiervorgang nebenher als root laufen.

/proc/meminfo ist auch als normaler Nutzer lesbar. Für was sonst braucht das Skript root-Rechte?

Ups! Danke für die Info. Ansonsten: Nein. Das Script braucht keine Root-Rechte.

[geoliver2104]

Danke für die Antworten !
Möchte mein Problem nochmal darstellen.
riesige Datei auf ext. USB-Stick kopieren.
die Kopierfortschrittsanzeige im MidnightCommander geht nahezu sofort auf 100% bleibt dort aber hängen.
der mc nimmt dann auch keine Eingaben mehr entgegen. Im ersten Augenblick denkt man da einen kompletten Absturz des mc.
Je nach Dateigröße kann das schon mehrere Minuten andauern. Als einfacher USER weiß man gar nicht was da vorgeht.
Wenn man das script track-dirty von @heisenberg mitlaufen lässt, sieht man schön den Kopierfortschritt.
Das zählt herunter und beim Erreichen von Null, kann man auch wieder mit dem MidnightCommander interagieren.

[geoliver2104]

Danke für die Antworten
möchte das Problem nochmal darstellen:
riesige Datei auf USB-Stick, mit z.b. MidnightCommander, kopieren.
die Kopierfortschrittanzeige ist rasend schnell auf 100%, bleibt dort aber hängen.
der mc nimmt dann auch keine Eingaben mehr entgegen, also wie kompletter Programmabsturz.
je nach Dateigröße kann dieser Zustand auch mehrere Minuten andauern.
der erste Gedanke war: was ist jetzt los ?
das script track-dirty von @heisenberg gibt schon Hilfestellung:
wenn bei Null angelangt, reagiert auch der mc wieder auf Eingaben.

[heisenberg]

Hallo geoliver2104,

die Verwirrung ist verständlich. Gleichzeitig ist das halt einfach so. Wenn man eine große Datei auf ein pot. langsames Speichermedium kopiert, dann dauert das seine Zeit. Das finde ich jetzt grundsätzlich nichts besonders überraschendes. Menschen die von Computern keine Ahnung haben, verstehen das nicht und werden da nicht zu 100% gut über den aktuellen Status informiert.

Grüße,
h.

[geoliver2104]

Danke für die Antworten
möchte das Problem nochmal darstellen:
riesige Datei auf USB-Stick, mit z.b. MidnightCommander, kopieren.
die Kopierfortschrittanzeige ist rasend schnell auf 100%, bleibt dort aber hängen.
der mc nimmt dann auch keine Eingaben mehr entgegen, also wie kompletter Programmabsturz.
je nach Dateigröße kann dieser Zustand auch einige Minuten andauern.
der erste Gedanke war: was ist jetzt los ?
das script track-dirty von @heisenberg gibt schon Hilfestellung:
wenn bei Null angelangt, reagiert auch der mc wieder auf Eingaben.

[TRex]

Falls du den editier-Button suchst: das ist der mit dem Stift.

[geoliver2104]

Bitte entschuldigt meine mehrfachen Postings, war mir nicht sicher ob schon abgeschickt oder nicht.
Ich glaub ich kenn mich jetzt aus.
Danke an alle und speziell an @heisenberg für das interessante Script !