Arch Linux

Kopieren auf USB Stick oder USB Festplatte (sync parameter)

cipher

Hallo zusammen,

Wenn ich große Dateien auf ein USB Gerät kopiere, egal ob Stick oder Festplatte, dauert es ja nach Größe eine weile bis die Dateien kopiert sind. Das ist ja auch abhängig von der Geschwindigkeit des Endgerätes.

Sagen wir ich kopiere eine 4GB große Datei von meiner internen Festplatte auf einen USB-Stick. Das dauert dann so ca 3 Minuten, je nach Stick auch länger. Wenn der kopiervorgang fertig ist, und ich das Gerät trennen will dauert es mindestens nochmal solange bis er es trennt. In der zwischenzeit kommt die Meldung "Daten auf Gerät schreiben". Er hat die Daten also nicht wirklich dorthin kopiert sondern nur in einen zwischenspeicher (cache), wo auch immer der liegt.

Nun zu meiner Frage.
Gibt es die Möglichkeit dieses verhalten abzustellen. So das die Daten direkt zum Stick oder USB-HDD kopiert werden. So das ich davon ausgehen kann wenn der Statusbalken 100% anzeigt auch wirklich alles kopiert ist?

Gruß

Ovion

Womit kopierst du?

LessWire

Der "sync" Parameter beim "mount" sollte helfen (siehe "man mount").

cipher

@Ovion

Kopiere mit Double-Commander oder Gnome-Commander.
Mit mc bzw cp habe ich noch nicht getestet. Vermute aber das die Software keine Rolle spielt.

Nachtrag:
Ich habe das jetzt mal mit mc getestet. Eine 4GB Datei kopieren dauert ca 4 Minuten. Wenn ich jetzt trennen will, kommt ca 10 Minuten Gerät bitte nicht trennen.

@LessWire
Die USB-Geräte werden ja, zumindest meistens, automatisch eingebunden. Ich mounte nicht über die Konsole.

@all
Habe vergessen zu erwähnen ich nutze xfce.
Ich habe in einem anderen Thread was über den Write-Cache und sync gelesen.
https://forum.archlinux.de/viewtopic.php?id=14292

Nur wo soll ich den sync Parameter angeben, da XFCE das mounten übernimmt, bzw ich über das Desktop Icon das Device einbinde.

Gruß

dagget

https://wiki.archlinux.de/title/Udev

Theoretisch sollte eine Regel unter /etc/udev/rules.d/ zu finden sein, die deine Geräte einbindet.

LG
Markus

cipher

dagget schriebhttps://wiki.archlinux.de/title/Udev

Theoretisch sollte eine Regel unter /etc/udev/rules.d/ zu finden sein, die deine Geräte einbindet.

LG
Markus

ls -al /etc/udev/rules.d/

insgesamt 16
drwxr-xr-x 2 root root 4096 16. Jan 2013  .
drwxr-xr-x 4 root root 4096 20. Dez 17:11 ..
-rw-r--r-- 1 root root  377  6. Okt 2012  01-touchpad.rules
-rw-r--r-- 1 root root  487 16. Jan 2013  80-net-name-slot.rules

cat /etc/udev/rules.d/80-net-name-slot.rules 

# This file masks persistent renaming rules for network devices. If you
# delete this file, /usr/lib/udev/rules.d/80-net-name-slot.rules may
# rename network devices according to ID_NET_NAME_{ONBOARD,SLOT,PATH}
# properties of your network devices, with priority in that order. See
# the output of 'udevadm test-builtin net_id /sys/class/net/$interface'
# for details on what that new name might be.
# 
# http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames

Die 01-touchpad.rules ist von mir erstellt, und sollte bwerkstelligen das beim einstecken der Maus das Touchpad abgeschaltet wird. Hat aber nie funktioniert.
Die 80-net-name-slot.rules ist wohl eine vom System erstellte Datei, aber leer bzw auskommentiert.

Muss ich hier eine Regel erstellen? Und wenn ja was muss da rein, habe keine Ahnung von udev.

Gruß

cipher

Schieb

cipher

Hallo zusammen,

Ich möchte das Thema gerne nochmal angehen, da ich bis jetzt noch keine Lösung gefunden habe.

Ich benutze XFCE. Beim einstecken eines USB-Sticks wird er automatisch gemountet.
Im mount befehl steht dann:

/dev/sdb1 on /run/media/cipher/SanDisk16GB type fuseblk (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096)

oder

/dev/sdb1 on /run/media/cipher/CBDA-6274 type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=100,fmask=0022,dmask=0077,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)

Wie kann ich fuse bzw. gvfs mitteilen das er beim mounten den sync Parameter nutzen soll?
Funktioniert das überhaupt mit udev, da ja hier gvfs genutzt wird?

Was beim einstecken eines USB-Massenspeichers genau passiert ist mir nicht bekannt. Vielleicht kann mir da jemand mal auf die Sprünge helfen.

Gruß

Martin-MS

Vergiss die "sync"-Option, das macht alles nur noch langsamer! Ich kann mich daran erinnern, dass in grauen Vorzeiten als ich noch SUSE verwendete in einer Version jeder USB-Datenträger standardmäßig so eingehängt wurde was zu allgemeinem Protest führte da die Schreibrate inakzeptabel einbrach. In der folgenden Version hat man es dann wieder heraus genommen.

Die "sync"-Option soll mehr Sicherheit bei Wechseldatenträgern geben weil dabei jeder Block sofort auf den Datenträger zurückgeschrieben und nicht gepuffert wird; soweit die Theorie. Es soll vor Datenverlust schützen wenn der Stick einfach herausgezogen wird bevor die Anwendung ihren Schreibvorgang beendet hat. Als negativen Seiteneffekt führte es dazu, dass die schreibende Anwendung so lange warten musste bis die Daten wirklich auf den Datenträger geschrieben wurden, und der zusätzliche Verwaltungsaufwand eines jeden Schreibvorgangs führte dann dazu, dass es richtig langsam wurde.

Das von dir beobachtete Verhalten ist ganz normal und auch der beste Kompromiss, wenn es um Sicherheit und Geschwindigkeit geht, erfordert aber auch etwas mehr Disziplin im Umgang mit externen Speichermedien. Jetzt gibt die schreibende Anwendung seine Daten zunächst an das System ab und kann dann auch beendet werden, während sich das System dann im Hintergrund um den endgültigen Schreibvorgang kümmert. Der Flaschenhals ist ja der USB-Anschluss und der Stick. Dass eine 4GB große Datei nicht wirklich in 3 Minuten auf den Stick zu kopieren ist, sollte eigentlich klar sein. Hier wird dank (wahrscheinlich) üppigem Speicherausbau ein Großteil gepuffert, die Anwendung wird wieder frei und der Puffer wird dann nach und nach auf den Stick geschrieben. In Summe wirst du dann immer deine 6 Minuten warten müssen, so oder so.

Beim "umount" wird dann implizit auch ein "sync" abgesetzt der sinnvollerweise auch dann erst ins Ende kommt wenn sich der Pufferinhalt komplett auf dem Stick befindet und erst dann getrennt wird. Man kann auch auf der Konsole manuell ein "sync" absetzen, wenn der Puffer sofort geschrieben werden soll, sonst passiert es im Hintergrund bei geringer Systemauslastung.

Du kannst das aber auch gerne mal selber versuchen, indem du den Stick auf der Konsole manuell mit der "sync"-Option einhängst (ggfls. vorher mit "umount" aushängen falls xfce ihn sich schon vorher gekrallt hat) und dann mal deine 4GB auf den Stick schreiben und über deine Erfahrungen berichten. Wenn du danach immer noch die "sync"-Option beim automatischen einhängen möchtest können wir uns ja noch mal damit beschäftigen, wie die udev-Regel dazu aussehen muss.

cipher

Hi,

@Martin-MS

Bleiben wir bei den Beispiel 4GB/3Minuten, egal ob USB-Stick oder USB-HDD.

Wenn ich unter Windows eine Datei kopiere dauert das 3 Minuten.
Dann klicke ich auf Trennen und innerhalb von ein paar Sekunden kann ich den Stick abziehen.
Sofern der Windows-Explorer dann nicht rumzickt, aber das ich eine andere Geschichte.

Wenn ich unter Linux eine Datei kopiere dauert das auch 3 Minuten.
Wenn ich dann auf Trennen klicke dauert es nochmal 2-3 Minuten bis alle Daten auf das Medium geschrieben sind.

Mit zunehmender Datenmenge steigt logischerweise auch proportional die Zeit für den Kopiervorgang. Aber auch die Zeit für den Trennungs-Sync steigt an.
Soll heißen 3 Minuten kopieren = 3 Minuten sync, 10 Minuten kopieren = 10 Minuten sync nach oben keine Grenzen.

Wenn ich rein rechnerisch 12GB kopiere dauert das dann 9-10 Minuten. Wenn ich trenne nochmal 9-10 Minuten. Das ist jetzt natürlich nicht ausgemessen sondern ein ungefährer Wert, Plusminus 1-2 Minuten.

Durch den sync beim mounten will ich erreichen das die zweite Wartezeit entfällt. Zumal ich dort auch keinen Fortschrittsbalken habe.

Ich werde mal testen, indem ich den Stick unmounte und dann mit der sync Option nochmals mounte. Ob sich dahingehend was verändert.

maltem

Zur Inspiration: Ich hatte mal einen Laptop, bei dem Linux aus unbekannten Gründen riesige Probleme mit USB-Speichern hatte, auch mit USB-Festplatten – es war alles viel langsamer als gedacht. Ich vermutete ein echtes Problem mit dem USB-Bus oder Bios, hatte das aber nicht weiterverfolgt.

cipher

Martin-MS schriebDu kannst das aber auch gerne mal selber versuchen, indem du den Stick auf der Konsole manuell mit der "sync"-Option einhängst (ggfls. vorher mit "umount" aushängen falls xfce ihn sich schon vorher gekrallt hat) und dann mal deine 4GB auf den Stick schreiben und über deine Erfahrungen berichten. Wenn du danach immer noch die "sync"-Option beim automatischen einhängen möchtest können wir uns ja noch mal damit beschäftigen, wie die udev-Regel dazu aussehen muss.

OK, ich gebe mich geschlagen.

Nach 5 Minuten und 10% habe ich abgebrochen. Er kopiert dann mit 'sagenhaften' 1,2 MB/s.
Beim normalen mounten hat der Kopiervorgang 2:17 Minuten, und das trennen 1:40 Minuten gedauert. Die Datei war 4,3 GB groß.

Unter Windows ist der Zeitaufwand ja ungefähr gleich. Der Unterschied ist, es muss nach dem Kopiervorgang nicht gesync werden. Der Stick kann, muss aber nicht, per Software getrennt werden.

Ich dachte durch den sync Parameter würde ich das verhalten von Windows erreichen. So das beim trennen kein Zeitaufwand notwendig wird.
Bei dem Beispiel ist es ja noch im Zeitrahmen. Wenn ich aber mal 30-50 GB kopiere ist es nervig eine halbe Stunde auf den Trennungs-Sync zu warten. Schade, aber ist nunmal so.

@all
Danke für eure Mithilfe

Ovion

kannst aus cp ja eine Funktion machen:

function cp() {
  /usr/bin/cp $@
  sync
  echo 'Kopiervorgang abgeschlossen'
}

Damit sollte das syncen vor'm trennen entfallen und cp hat nix damit zu tun, genausowenig wie die mount-Optionen.

cipher

Gute Idee.
Das würde zumindest für die Konsole helfen, und eventuell noch beim mc. Keine Ahnung ob er cp nutzt.
Aber bei Double-Commander bzw Gnome-Commander nicht.

Wie gesagt, ich finde mich damit ab das es so ist.

Martin-MS

cipher schriebNach 5 Minuten und 10% habe ich abgebrochen. Er kopiert dann mit 'sagenhaften' 1,2 MB/s.
Beim normalen mounten hat der Kopiervorgang 2:17 Minuten, und das trennen 1:40 Minuten gedauert. Die Datei war 4,3 GB groß.

OK; ist dann schon so wie ich es mir gedacht hatte.
Hat der Stick oder die Platte eine LED, an der man die Aktivitäten erkennen kann? Leuchtet/flackert die bei der ersten Phase des Kopiervorgangs, also schon bevor die Anwendung das Ende des Kopiervorgangs meldet? Und was passiert danach? Eigentlich müsste sie danach weiter flackern wenn im Hintergrund der Puffer auf den Datenträger geschrieben wird, spätestens beim trennen. Oder wird erst geschrieben wenn das Trennen angefordert wird? Handelt es sich um ein USB2- oder USB3-Gerät, auf das geschrieben werden soll?
Ich finde das schon etwas seltsam, dass für das Trennen noch einmal die gleiche Zeit wie für das Kopieren aufgewendet werden muss. Da beispielsweise bei den 50GB nur ein kleiner Teil im Speicher gehalten werden kann müsste der größte Zeitaufwand beim Kopieren entstehen und ein vergleichsweiser geringer Teil beim Trennen, weil in diesem Moment nur noch der Cache geleert werden muss, der wiederum auch nur einen Teil des Gesamtspeichers belegt.

Martin-MS

Ovion schriebkannst aus cp ja eine Funktion machen:
Damit sollte das syncen vor'm trennen entfallen und cp hat nix damit zu tun, genausowenig wie die mount-Optionen.

Damit verschiebt sich das Problem aber nur. Der Zeitaufwand wird am Ende identisch sein, ob er nun direkt nach dem cp noch ein sync absetzt oder beim trennen der sync automatisch abläuft.

Ovion

Martin-MS schriebDer Zeitaufwand wird am Ende identisch sein, ob er nun direkt nach dem cp noch ein sync absetzt oder beim trennen der sync automatisch abläuft.

Ist er ja offenbar nicht, 2:17+1:40 verglichen mit 5min für 10%.

Ich vermute, dass der Kernel einfach raw daten schreibt, während beim Kopiervorgang Dateien geschrieben werden. Wird nun beides gleichzeitig gemacht, kommt der Flaschenhals von beiden kombiniert zum Tragen.

cipher

@Martin-MS

Ich habe das heute mit einer USB 2.0 Festplatte getestet. Beim Kopiervorgang blinkt die LED kontinuierlich. Danach blinkt sie noch ab und an. Erst wenn ich trenne blinkt es kräftig weiter.
Was auffällt das die Geschwindigkeit mit der kopiert wird auf dem USB-Bus nicht möglich ist. Er zeigt mir 150 MB/s an, was sich langsam aber sicher nach unten bewegt. Bei ca. 30 MB/s pendelt er sich ein. Was auch realistisch ist bei USB 2.0.

Was darauf hindeuten würde, das nach dem eigentlichen Kopiervorgang zunächst mal nichts mehr oder zumindest wenig passiert. Erst wenn ich auf Trennen gehe wird dann der Rest aus dem Cache geschrieben.

Was ich diesmal nicht getestet hatte, aber mich aus der Vergangenheit noch erinnere. Wenn ich etwas kopiert hatte, und die Platte dann noch eine Weile angeschlossen hatte, weil ich gerade nicht an Laptop war, hat er für die Trennung immer noch eine Weile benötigt. Vielleicht nicht gerade so lange wie als wenn ich direkt trennen würde, aber in der Zeit zwischen dem fertigstellen des Kopierens und dem Trennvorgang scheint das keine Priorität zu haben.

cipher

Ovion schrieb
Martin-MS schriebDer Zeitaufwand wird am Ende identisch sein, ob er nun direkt nach dem cp noch ein sync absetzt oder beim trennen der sync automatisch abläuft.
Ist er ja offenbar nicht, 2:17+1:40 verglichen mit 5min für 10%.

Ich vermute, dass der Kernel einfach raw daten schreibt, während beim Kopiervorgang Dateien geschrieben werden. Wird nun beides gleichzeitig gemacht, kommt der Flaschenhals von beiden kombiniert zum Tragen.

Ja mit der Option sync kopiert er nur mit 1,2 MB/s. Was nach USB 1.1 aussieht.
Ich habe lediglich eine 4,3 GB große Datei von der internen Platte (SSD) auf die USB-HDD kopiert.

Ich habe die Tests nicht gleichzeitig gemacht.
Einmal mit dem Standard-Mount über das Desktop Icon in XFCE. Dann getrennt, und nochmal eingesteckt und per Konsole mit

mount -t ntfs -o sync /dev/sdb1 /mnt

gemountet.

Martin-MS

So, ich habe es jetzt auch einmal getestet, um Vergleichswerte zu bekommen. Kommandozeile war

time cp <QUELLDATEI> . && time sync

Damit sehe ich, welcher Anteil der Gesamtkopierzeit auf die Kopie und das Schreiben des Puffers entfällt.

cp:
real 2m19.368s
user 0m0.030s
sys 0m7.293s

und sync:
real 0m8.338s
user 0m0.000s
sys 0m0.027s

Quelle war eine SSD Ziel eine USB3-Festplatte im USB2-Modus, Verschlüsselung auf bedien Seiten, kommt also noch der Transport durch den Device-Mapper hinzu. Dennoch zumindest was den ersten Teil betrifft in deinem Zeitrahmen.

Was mir noch aufgefallen ist:

mount -t ntfs -o sync /dev/sdb1 /mnt

Hast du mal den mount mit ntfs-3g versucht? (evtl. das betreffende Paket nachinstallieren) Und tritt das Verhalten auch mit ext3/4-Dateisystemen auf?

Nächste Seite »