# kopieren mit kde

## Christian99

Hallo, ich kopiere immer mit kde (krusader) Musik auf mein Handy, welches als Massenspeicher (USB) angeschlossen ist, was immer ziemlich langsam ist (30  kB/s). Jetzt hab ich zufällig festgestellt, wenn ich über die Konsole kopiere, dann läufts mit ca 90 kB/s (ich weiß, immer noch verdammt langsam, aber immerhin das dreifache) Hat jemand ne Ahnung was KDE da treibt, dass es diesen Unterschied gibt? ich find das doch ziemlich krass.

Schöne Grüße

Christian

----------

## bas89

Ist das wirklich dreimal schneller (hast du das mal überprüft) oder steht es nur da? Geschwindigkeitsanzeigen sind in KDE immer mit Vorsicht zu genießen (Meine Erfahrung).

----------

## Christian99

ich nehm beides mal den wert des systemmonitor->Festplattendurchsatz->sdd1->Ändern->Daten schreiben. dass es nicht ganz zuverlässig ist hab ich auch schon beobachtet, aber da ich beides mal auf den selben sensor schaue, dachte ich es ist halbwegs vergleichbar

----------

## bas89

Naja ich mein, kopier doch eine Datei rüber und miss die Zeit  :Smile: 

----------

## Christian99

time cp ./test.file /media/Handy/

real 1m28.643s

user 0m0.001s

sys 0m0.129s

unter kde mit auf die uhr schauen macht 4min55sek....

----------

## bas89

Hmpf.  Das ist ja schon nicht wegzudiskutieren. Worans liegt kann ich dir nicht sagen :\

----------

## manuels

Mountest du einmal mit mount und einmal mit KDE?

Falls dem so ist, schau dir mal an, was für mount-Optionen jedes Mal genutzt werden.

----------

## Christian99

nein, ist beides male der selbe mount:

/dev/sdc1 on /mnt/sdc1 type vfat (rw,sync,relatime,gid=100,umask=002)

----------

## SvenFischer

Also ich habe das auch schon beobachtet. Ich habe das Gefühl, das wenn mehrere Dateien kopiert werden, KDE das parallel macht im Gegensatz zur Konsole. Scheinbar führt das zu Verzögerungen.

Probier doch mal nur eine große Datei zu kopieren.

----------

## Christian99

der test mit der zeitmessung war eine einzelne Datei. Nach meinen beobachtungen werden parallele kopiervorgänge gestartet wenn man auc zwei kopiervorgänge startet. wenn man mehrere dateien auf einmal kopiert, wird auch da nur eine nach der anderen kopiert.

----------

## Josef.95

 *Christian99 wrote:*   

> nein, ist beides male der selbe mount:
> 
> /dev/sdc1 on /mnt/sdc1 type vfat (rw,sync,relatime,gid=100,umask=002)

 

Hmm. bist du dir da sicher?

Beachte das kde evtl. HAL zum mounten nutzt (sofern das Laufwerk noch nicht eingebunden ist) und HAL muntet afaik per default nach /media/*

Lass doch sonst einfach mal ein "tail -f /var/log/messages" mitlaufen, evtl. ist dort eher ersichtlich was KDE da eigentlich macht... ;)

----------

## Christian99

ganz sicher kein hal. gemountet wird über udev.

während des kopierens mit kde wird auch nichts ins kernellog geschrieben.

----------

## Mr. Anderson

Ich kann mir vorstellen, dass Dolphin oder Konqueror immer wieder den Verzeichnisinhalt neu lädt, weil sich regelmäßig was ändert, möglicherweise auch noch mit Dateivorschau. Schließ doch mal alle Dolphin- oder Konqueror-Fenster während der Kopiervorgang läuft (das Kopieren sollte ja weiter laufen).

----------

## Christian99

nein, krusader zumindest refresht nicht automatisch, nur wenn ich es explizit sage. Und bei der zeitmessung war er schon geschlossen.

----------

## Mr. Anderson

Geht es mit dd schneller? Eventuell auch mit unterschiedlichen Blockgrößen (bs=foo).

----------

## manuels

Nutzt cp vielleicht den OS-Cache zum Schreiben?

Mess mal bitte die Zeit für "cp file /mnt/usb && umount /mnt/usb".

----------

## Christian99

nein, tut es nicht. ich hab mit mountoption sync gemountet extra deswegen. sonst kopieren beide wesentlich schneller. und ich muss noch ewig bis zum abstöpseln warten, ohne genau zu wissen wie lange.

----------

## mv

Ich vermute, dass kde vielleicht während des Kopierens ab und zu sync() aufruft (etwa sobald der interne Puffer leer ist).

 *Christian99 wrote:*   

> nein, tut es nicht. ich hab mit mountoption sync gemountet extra deswegen.

 

Bei Medien, die nur eine begrenzte Zahl an Schreibvorgängen haben, würde ich das möglichst vermeiden.

 *Quote:*   

> und ich muss noch ewig bis zum abstöpseln warten, ohne genau zu wissen wie lange.

 

Bei der Shell weißt Du das: Sobald umount zurückkehrt. Wie man das bei KDE kontrolliert, weiß ich nicht - ist vermutlich bei kde-4.6 mit dem u*-Ranz auch schon wieder anders.

----------

## Christian99

 *Mr. Anderson wrote:*   

> Geht es mit dd schneller? Eventuell auch mit unterschiedlichen Blockgrößen (bs=foo).

 

sorry, hab ich beim letzten post überlesen, werd ich mal noch probieren.

 *mv wrote:*   

> Bei Medien, die nur eine begrenzte Zahl an Schreibvorgängen haben, würde ich das möglichst vermeiden. 

 

wieso eigentlich? was genau passiert da anders? ich find es halt unschön, dass er nach 5 Minuten mit dem kopieren fertig ist, in wahrheit aber noch nen halben tag lang daten verschiebt.

----------

## mv

 *Christian99 wrote:*   

> wieso eigentlich? was genau passiert da anders?

 

Wenn Du beispielsweise zwei Dateien hintereinander in das selbe Directory kopierst, wird (mindestens) der Directory-inode verändert, bei vernünftigem Caching hingegen nur einmal. Je nach Implementation kann das mehrfache Schreiben sogar passieren, wenn Du die Dateien "auf einen Schlag" (mit einem Kommando bzw. einem Ziehen mit der Maus) kopierst.

----------

## manuels

 *mv wrote:*   

> Wenn Du beispielsweise zwei Dateien hintereinander in das selbe Directory kopierst, wird (mindestens) der Directory-inode verändert, bei vernünftigem Caching hingegen nur einmal.

 Meinst du zwei mal die selbe Datei?

EDIT: Meinst du, dass die Änderung des Inodes wirklich so stark ins Gewicht fällt?

----------

## mv

 *manuels wrote:*   

>  *mv wrote:*   Wenn Du beispielsweise zwei Dateien hintereinander in das selbe Directory kopierst, wird (mindestens) der Directory-inode verändert, bei vernünftigem Caching hingegen nur einmal. Meinst du zwei mal die selbe Datei?

 

Nein.

 *Quote:*   

> EDIT: Meinst du, dass die Änderung des Inodes wirklich so stark ins Gewicht fällt?

 

Der Inode ist das Minimum, was doppelt geschrieben wird. Je nach Filesystem und wie oft sync() aufgerufen wird, können da wesentlich mehr Daten mehrmals geschrieben werden - im worst case wird nach jedem Datenblock ein Metadatenblock verändert und geschrieben. Unabhängig davon wäre selbst nur ein doppelt geschriebener Inode unnötig - also wieso unnötigerweise Daten doppelt schreiben?

----------

## Randy Andy

Hi Leute,

einen hab ich noch...

Hab vor Zwei Tagen versucht ein dd-Image von knapp 20GB mit dolphin und dem fish://user@host oder auch mittels sftp://user@host zu kopieren, und kam nur auch schlappe 1 bis 3 Mib/s, bei einer 100Mbit Lan-Verbindung.

Dachte schon ich müsste mich auf die Suche nach Kabelfehlern o.ä. machen.

Dann hab ich mit mii-tool mal geguckt ob auch die 100Mbit Verbindung steht - i.o.

Dann hab ich's mal mit Midnight-Commanders shell Verbindung versucht, und siehe da, über 20Mib/s.

Ist Euch das bekannt? Ist's mit KDE-4.6-sc schon gefixed, und wann ist das endlich im Tree? Habe gerade noch gesynced - nada (lechz).

Schönen Abend Euch,

Andy.

----------

## hurra

 *Randy Andy wrote:*   

> Dann hab ich's mal mit Midnight-Commanders shell Verbindung versucht, und siehe da, über 20Mib/s.

 

Wie kannst du ~20 MB/s bei ner 100Mbit/s Verbindung schaffen?

----------

## Randy Andy

Nu schrei nicht gleich Hurra   :Wink: 

Rein rechnerisch haste ja recht.

Ich hab ja auch nur das angegeben was der Midnight Commander mir anzeigt, wobei ich mich da leider etwas korrigieren muss, denn:

Der mc zeigte tatsächlich 20MB/s an und nicht in Mib/s wie der Dolphin, was jedoch noch eine relativ geringe Abweichung ist.

Wir erinnernt uns:

Megabyte (MB)  = 1.000.000 Byte

Mebibyte (MiB)  = 1.048.576 Byte

Man sieht mal wieder dass die Angaben nicht stimmen.

Trotzdem hat dolphin für die Übertragung über 3:30 Stunden gebraucht,

der mc keine halbe Stunde.

Es gibt also einen massiven Geschwindigkeitsunterschied, und darauf wollte ich aufmerksam machen.

Kann oder möchte das jemand bestätigen, ist das bekannt, weiss man woran es liegt?

Fragen über Fragen.

Gruß, Andy.

----------

