user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17552
Wohnort: Berlin
|
sajder schrieb: Die Durchschnittswerte nach mehreren Kopiervorgängen, mit einer 500MB Datei. cp-Terminal –- dient als Basis Vergleich Midnight Commander - MC –- ca.=0 Sekunden –- kein Unterschied Thunar –- ca.+22 Sekunden PCManFM / Nautilus / Caja –- ca.+22 Sekunden –- ähnlich schnell wie Thunar XFE –- ca.+70 Sekunden –- hat mich überrascht, extrem langsam
Ohne Basiswert nur halb so interessant. Wenn das eine Programm 1s und das andere 70s braucht, dann ist das bemerkenswerter, als wenn das eine 1000s und das andere 1070s braucht. picnerd schrieb:
Eine Frage: Wie misst du die Zeit? Nur so als Info.
Eben. Fesplatten- bzw. USB-LED beobachtet? Man weiß nicht, ob das System schon fertig ist, oder das eine Programm vielleicht eine Vollzugsmeldung abwartet, das andere nicht.
Das MC als Terminal-Dateimanager keinen unterschied zeigt bringt mich auf den Gedanken das Problem beim programmieren eines Grafischen-Dateimanagers zu suchen. Da mir aber die Programmierkentnisse fehlen kann ich da nichts zu beitragen. user_unknown hat da ja tiefer gehende Kenntnisse glaube ich.
Nur wenige. Ich habe überprüft, wie lange es dauert mit Java-Swing einen File-Open-Dialog für /usr/bin anzuzeigen, und es war deutlich länger als bei mc, aber deutlich kürzer als bei Thunar. Ob ich damals tumblerd installiert hatte und auf klugen Hinweis deaktiert habe, an etwas derartiges erinnere ich mich jedenfalls nicht mehr - jedenfalls nicht zwischen den Messungen. Man kann auch generisch leicht ein Menü mit 9 Einträgen generieren, jedes mit 9 Untereinträgen, die ihrerseit 9 Untereinträge haben mit weiteren 9 ... usw., so dass das Gesamtmenü 10000 und mehr Einträge hat. Auch das ging mit Java-Swing rasend schnell und ohne irgendwelche Optimierungen und Insidertricks. Macht tumbler von Videos dann animierte GIFs als Vorschaubild, oder was ist da los?
|
Vegeta
Anmeldungsdatum: 29. April 2006
Beiträge: 7943
|
sajder schrieb: Nein, kein unterschied. Außer das man der Datei zuschaut, wie die MB Werte ansteigen 😉.
Wenn es nicht an tumblerd liegt, dann weiß ich es auch nicht. Entweder laufen während des Kopierens noch weitere Hintergrundprozesse ab, die man nicht sieht, oder aber Thunar benutzt nicht die volle Geschwindigkeit beim Kopieren. Das kann gewollt sein um nicht andere Programme auszubremsen die eventuell ebenfalls das Laufwerk benutzen oder weil es nicht optimal programmiert ist. user_unknown schrieb: Es gibt eigentlich keinen Anlass dafür. Das Verschieben oder Kopieren einer Datei dürfte ja dessen Thumbnnnail nicht ändern. Man kann den Thumbnail ja mitkopieren. Außer dieser tumbler ist tumb und kriegt gar nicht mit, was läuft, nur wo Dateien auftauchen und arbeitet dann los.
Das kannst du ja gerne selber mal testen. Die Thumbnails werden in ~/.thumbnails/ gespeichert. Als Namen wird da höchstwahrscheinlich ein Hash-Wert benutzt, es sind jedenfalls nicht die Originalnamen. Dass die Thumbnails aber mitkopiert werden dagegen spricht schon meine Beobachtung, dass diese Vorschaubilder sich beim Kopieren ändern können.
Wenn er einfach dazwischen hängen würde, nicht. Die Datei ist ja schon gelesen worden und muss sowieso geschrieben werden - die Analyse für ein Thumbnail könnte also in RAM und CPU stattfinden ohne Quell- und Zielmedium ein 2. Mal zu bemühen.
tumblerd ist ein dauerhafter Hintergrundprozess, wäre er eng mit Thunar verknüpft, dann könnte er bei Bedarf gestartet werden - wird er aber nicht. Zudem würde tumblerd dann nicht mehr mit anderen Dateimanagern funktionieren. Was das Übergeben von gebufferten Daten angeht, das geht nicht. Thunar oder tumblerd müssten dann die ganze Datei im Speicher belassen, denn um einen Thumbnail zu generieren von einem Video, braucht es zwingend den kompletten Stream. Würde man dann ein HD-Video kopieren, die gerne mal zig Gigabyte groß sind, könnte das schnell selbst moderne Systeme in die Knie zwingen. Folglich gibts nur die Lösung, dass tumblerd die Datei einliest sobald sie sich ändert und das ist bei einem Kopiervorgang halt sehr oft der Fall.
Man kann auch in Thunar /usr/bin öffnen und staunen, wie lange es dauert erstmalig die 2000 Dateien zu parsen, nur um 25 davon anzuzeigen (begrenzte Fenstergröße). Pro Bootvorgang kann man das zwar nur 1x beobachten, weil die Ergebnisse dann gecached werden, aber trotzdem völlig unverständlich. MC < 1s. Dazu kommt, dass das Programmicon in den 2000 Fällen identisch ist, das sind nicht etwa 2000 verschiedene!
Das ist meiner Meinung nach den Vorschaugrafiken geschuldet. Einerseits müssen bestehende Thumbnails eingelesen oder sogar erstellt werden, wenn keine Vorschau möglich ist, dann wird ein Icon stattdessen angezeigt das auch erst geladen werden muss. Gibt es keine Dateiendung wird eventuell der Anfang der Datei geladen und analysiert, um was es sich handelt und dann entschieden was für ein Icon angezeigt wird. Das alles frisst Zeit, das alles macht MC nicht und deswegen ist es auch so schnell. Das kann man auch beim Double Commander beobachten, hat eine hübsche GUI und ist mit Qt programmiert /usr/bin wird da auch innerhalb von 1-2 Sekunden angezeigt.
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17552
Wohnort: Berlin
|
Vegeta schrieb: sajder schrieb: Nein, kein unterschied. Außer das man der Datei zuschaut, wie die MB Werte ansteigen 😉.
... oder aber Thunar benutzt nicht die volle Geschwindigkeit beim Kopieren. Das kann gewollt sein um nicht andere Programme auszubremsen die eventuell ebenfalls das Laufwerk benutzen oder weil es nicht optimal programmiert ist.
Wäre aber doof, wenn sonst kein Prozess die Ressourcen braucht. Solche Entscheidungen sollte man dem Scheduler des Systems überlassen und nicht diesen in jedem Programm auf eigene Faust nachprogrammieren, oder?
user_unknown schrieb: Es gibt eigentlich keinen Anlass dafür. Das Verschieben oder Kopieren einer Datei dürfte ja dessen Thumbnnnail nicht ändern. Man kann den Thumbnail ja mitkopieren. Außer dieser tumbler ist tumb und kriegt gar nicht mit, was läuft, nur wo Dateien auftauchen und arbeitet dann los.
Das kannst du ja gerne selber mal testen. Die Thumbnails werden in ~/.thumbnails/ gespeichert. Als Namen wird da höchstwahrscheinlich ein Hash-Wert benutzt, es sind jedenfalls nicht die Originalnamen. Dass die Thumbnails aber mitkopiert werden dagegen spricht schon meine Beobachtung, dass diese Vorschaubilder sich beim Kopieren ändern können.
Dafür müsste ich erst mal tumblerd installieren. Ich denke nicht, dass ich das machen werde.
Wenn er einfach dazwischen hängen würde, nicht. Die Datei ist ja schon gelesen worden und muss sowieso geschrieben werden - die Analyse für ein Thumbnail könnte also in RAM und CPU stattfinden ohne Quell- und Zielmedium ein 2. Mal zu bemühen.
tumblerd ist ein dauerhafter Hintergrundprozess, wäre er eng mit Thunar verknüpft, dann könnte er bei Bedarf gestartet werden - wird er aber nicht. Zudem würde tumblerd dann nicht mehr mit anderen Dateimanagern funktionieren.
Er könnte sich ja bei den Dateimanagern anmelden, um benutzt zu werden. Wenn diese keine Schnittstelle bieten könnte er immer noch arbeiten wie sonst. Er könnte sich aber auch beim Kernel registrieren, um über Dateiverschiebungen und -kopien informiert und zwischengeschaltet zu werden. Aber das sind wohl ungelegte Eier. Mir sagt apt-search:
| tumbler/xenial,now 0.1.31-2build2 amd64
D-Bus thumbnailing service
|
Ich dachte D-Bus spräche dafür, dass das auf einem Bussystem arbeitet, wo die Daten durchrauschen. ☺
Was das Übergeben von gebufferten Daten angeht, das geht nicht. Thunar oder tumblerd müssten dann die ganze Datei im Speicher belassen, denn um einen Thumbnail zu generieren von einem Video, braucht es zwingend den kompletten Stream. Würde man dann ein HD-Video kopieren, die gerne mal zig Gigabyte groß sind, könnte das schnell selbst moderne Systeme in die Knie zwingen. Folglich gibts nur die Lösung, dass tumblerd die Datei einliest sobald sie sich ändert und das ist bei einem Kopiervorgang halt sehr oft der Fall.
Wenn sie sich ändert ist es m.E. keine Kopie. Eine Kopie ist etwas identisches. Dass für das Thumbnail der ganze Strom im Speicher bleiben muss ist m.E. keine zutreffende Schlussfolgerung. Der ganze Datenstrom muss durch thumbler durch, aber davon muss immer nur ein Datenfenster voll gleichzeitig den Programmen zur Verfügung stehen. Die gesamte Arbeitskette ist dabei so langsam wie das langsamste Glied, und wenn das lesende Programm sehr viel schneller ist, als das schreibende, dann bremst entweder das langsamere das schnellere, oder die Datei staut sich tatsächlich größtenteils auf.
Man kann auch in Thunar /usr/bin öffnen und staunen, wie lange es dauert erstmalig die 2000 Dateien zu parsen, nur um 25 davon anzuzeigen (begrenzte Fenstergröße). Pro Bootvorgang kann man das zwar nur 1x beobachten, weil die Ergebnisse dann gecached werden, aber trotzdem völlig unverständlich. MC < 1s. Dazu kommt, dass das Programmicon in den 2000 Fällen identisch ist, das sind nicht etwa 2000 verschiedene!
Das ist meiner Meinung nach den Vorschaugrafiken geschuldet. Einerseits müssen bestehende Thumbnails eingelesen oder sogar erstellt werden, wenn keine Vorschau möglich ist, dann wird ein Icon stattdessen angezeigt das auch erst geladen werden muss.
Das muss nicht sein. Man kann erst die Dateinamen lesen und abhängig von den Userstettings (Fenstergröße, Auflösung, kleine oder große (Vorschau)bilder Platzhalterrahmen anzeigen mit den Dateinamen, und on the fly zuerst die Vorschaubilder laden oder generieren, die gerade im Fenster (Scrollen, Sortierreihenfolge, ...) sichtbar sein sollen und den Rest im Hintergrund laden, während man vorne schon was anzeigt. Das dauert kaum länger als stumpf alle Bilder zu laden/zu generieren, und erst anzufangen anzuzeigen, wenn man das letzte erzeugt hat.
|
Vegeta
Anmeldungsdatum: 29. April 2006
Beiträge: 7943
|
user_unknown schrieb: Wäre aber doof, wenn sonst kein Prozess die Ressourcen braucht. Solche Entscheidungen sollte man dem Scheduler des Systems überlassen und nicht diesen in jedem Programm auf eigene Faust nachprogrammieren, oder?
Das war lediglich eine Idee, was genau diese schlechtere Performance ausmacht. Möglich wäre auch, dass Thunar einen kleineren Lesebuffer benutzt, umso kleiner der Lesebuffer ist, umso länger dauert der Kopiervorgang.
Er könnte sich ja bei den Dateimanagern anmelden, um benutzt zu werden. Wenn diese keine Schnittstelle bieten könnte er immer noch arbeiten wie sonst. Er könnte sich aber auch beim Kernel registrieren, um über Dateiverschiebungen und -kopien informiert und zwischengeschaltet zu werden. Aber das sind wohl ungelegte Eier.
Die genaue Arbeitsweise kann leider keiner von uns benennen. Da müsste sich entweder jemand den Sourcecode anschauen oder einen der Entwickler bei https://git.xfce.org befragen. Vermutlich wird tumblerd eine kleine Schnittstelle bieten, damit ein Programm wie Thunar gezielt Vorschaugrafiken anfordern kann und im Gegenzug ein Signal bekommen, wenn dieses fertig ist. Viel mehr wird da wohl nicht laufen.
Wenn sie sich ändert ist es m.E. keine Kopie. Eine Kopie ist etwas identisches.
Jedes Programm kopiert eine Datei mittels eines Buffers, im englischen Chunks genannt, also in Teilen. Wenn also jedes Mal ein Stückchen gelesen und geschrieben wird, ändert sich logischerweise die unvollendete Kopie jedes Mal, bis sie komplett ist.
Dass für das Thumbnail der ganze Strom im Speicher bleiben muss ist m.E. keine zutreffende Schlussfolgerung. Der ganze Datenstrom muss durch thumbler durch, aber davon muss immer nur ein Datenfenster voll gleichzeitig den Programmen zur Verfügung stehen. Die gesamte Arbeitskette ist dabei so langsam wie das langsamste Glied, und wenn das lesende Programm sehr viel schneller ist, als das schreibende, dann bremst entweder das langsamere das schnellere, oder die Datei staut sich tatsächlich größtenteils auf.
Das angezeigte Thumbnail wird aus dem Video extrahiert und es ist abhängig von der Spieldauer des Films. Mit anderen Worten ist ein 100-Minutenfilm zu 50% kopiert (die unfertige Kopie hätte dann eine Spiellänge von 50 Minuten), wird ein anderes Thumbnail angezeigt als wenn z.B. 70% kopiert wurden. Wenn du aber nur den gerade aktuellen Buffer aufbewahrst, dann hast du ein Problem wenn du aus dem vorderen Bereich ein Thumbnail erzeugen willst.
Wenn ich die Vorschaugrafiken bei mir aufm Rechner anschaue, dann scheinen die Grafiken allesamt aus der ersten Hälfte eines Videos zu kommen. Aber du kannst das natürlich gerne selber genauer unter die Lupe nehmen.
Das muss nicht sein. Man kann erst die Dateinamen lesen und abhängig von den Userstettings (Fenstergröße, Auflösung, kleine oder große (Vorschau)bilder Platzhalterrahmen anzeigen mit den Dateinamen, und on the fly zuerst die Vorschaubilder laden oder generieren, die gerade im Fenster (Scrollen, Sortierreihenfolge, ...) sichtbar sein sollen und den Rest im Hintergrund laden, während man vorne schon was anzeigt.
Macht das Thunar bei dir nicht? Wenn ich z.B. den Order Bilder im Home-Ordner öffne, dann werden bei mir schnell die ersten Bilder angezeigt und Thunar rödelt im Hintergrund weiter. Wenn ich nun weiter nach unten scrolle kann man beobachten, wie die Vorschaubilder der Reihe nach generiert werden. Thunar berücksichtigt bei mir allerdings den aktuellen Sichtbereich (Viewport) und bevorzugt die Dateien die gerade betrachtet werden und erzeugt hier die Vorschaubilder zuerst. Das kann man selber schnell sehen, wenn man von ganz vorne zum Ende scrollt und Thunar nun diese Dateien bearbeitet.
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17552
Wohnort: Berlin
|
Wie gesagt, es war früher so, dass Thunar 30 Sekunden gebraucht hat, um im Ordner /usr/bin überhaupt was anzuzeigen, und als er dann soweit war waren es nur 2000 identische Icons. Heute verhält er sich nicht mehr so. Einerseits zeigt er sofort was an, andererseits eine kleine Variation an Icons.
|
Hans9876543210
Anmeldungsdatum: 2. Januar 2011
Beiträge: 3741
|
Kopiert denn Thunar tatsächlich mit cp als "Backend" oder nimmt Thunar gvfs-copy ? Ich vermute eher letzteres. Das wurde auch erklären, warum MC (ohne Gnome Optik) schneller ist (vermutlich nutzt MC dann cp ). Vielleicht ein Benchmark zwischen cp und gvfs-copy durchführen?
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17552
Wohnort: Berlin
|
Hans9876543210 schrieb: Kopiert denn Thunar tatsächlich mit cp als "Backend" oder nimmt Thunar gvfs-copy ? Ich vermute eher letzteres. Das wurde auch erklären, warum MC (ohne Gnome Optik) schneller ist (vermutlich nutzt MC dann cp ). Vielleicht ein Benchmark zwischen cp und gvfs-copy durchführen?
Das würde mich wundern, wenn auch nur einer von beiden auf das Programm "cp" zugreifen würde. Du kannst ja mal als sudo cp umbenennen, und sehen, ob Du weiter mit Thunar oder mc kopieren kannst. Wenn nicht, dann musst Du hoffen, dass mv nicht auch cp benutzt, sonst hast Du Dich wohl ausgesperrt. ☺ man -a cp liefert mir jedenfalls nur ein Programm cp, während man -a printf auch
PRINTF(3) Linux Programmer's Manual PRINTF(3)
NAME
printf, fprintf, dprintf, sprintf, snprintf, vprintf, vfprintf, vdprintf, vsprintf, vsnprintf - formatted output conversion
SYNOPSIS
#include <stdio.h>
eine C-Funktion gleichen Namens liefert. Zwar kann man erwarten, dass das Programm printf auf der C-Funktion beruht, wie eng habe ich aber noch nicht untersucht.
| type printf
printf ist eine von der Shell mitgelieferte Funktion.
# printf ist also ein in die Shell integriertes Programm, aber nicht nur:
which printf
/usr/bin/printf
type cp
cp ist /bin/cp
|
Cp gibt es nur als Programm, nicht als Shellfunktion. Das sind natürlich alles nur Indizien, aber für mich recht plausible um anzunehmen, dass sich die Programme da nicht auf andere Programme abstützen. Man handelt sich ja auch unschöne Abhängigkeiten ein. Beim Benchmarking jedenfalls Festplattenled im Auge behalten - nicht dass die Programme schummeln!
|
sajder
(Themenstarter)
Anmeldungsdatum: 1. März 2017
Beiträge: 19
|
user_unknown Ohne Basiswert nur halb so interessant. Wenn das eine Programm 1s und das andere 70s braucht, dann ist das bemerkenswerter, als wenn das eine 1000s und das andere 1070s braucht.
1GB Datei auf USB2-Stick kopiert. (Im 'fstab' mit 'sync' eingetragen)
(Durchschnitt aus drei Kopiervorgängen) 1m34s cp, mc (Terminal) 2m22s gvfs-copy, gio copy (Terminal) 2m18s Thunar, PCManFM, Nautilus, Caja, emelFM2 4m01s XFE
Eben. Fesplatten- bzw. USB-LED beobachtet? Man weiß nicht, ob das System schon fertig ist, oder das eine Programm vielleicht eine Vollzugsmeldung abwartet, das andere nicht.
Ja hab ich. Nach dem Kopiervorgang den USB-Stick sofort ausgeworfen, ohne Probleme.
Macht tumbler von Videos dann animierte GIFs als Vorschaubild, oder was ist da los?
Bei Video wird ein einfaches Vorschaubild angezeigt. Aber ich persönlich kann gut auf Vorschaubilder bei 'Thunar' oder 'ristretto' verzichten. Einerseits ist dann 'Thunar' beim öffnen eines Verzeichnisse mit mehreren tausend Dateien schneller und andererseits entsteht kein extra RAM verbrauch. Hans9876543210 Vielleicht ein Benchmark zwischen cp und gvfs-copy durchführen?
1GB Datei auf USB2-Stick kopiert. (Im 'fstab' mit 'sync' eingetragen)
(Durchschnitt aus drei Kopiervorgängen)
user_unknown Das würde mich wundern, wenn auch nur einer von beiden auf das Programm "cp" zugreifen würde.
'gvfs-copy' braucht wesentlich mehr Zeit als 'cp'. Also mit 'cp' bin ich sehr zufrieden, ist aber auch Gewohnheitssache, die ich jetzt mehr schätze und nutze.
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17552
Wohnort: Berlin
|
sajder schrieb:
Also mit 'cp' bin ich sehr zufrieden, ist aber auch Gewohnheitssache, die ich jetzt mehr schätze und nutze.
Tja - das alte Mantra: Die Shell ist userfriendly. Klickibunti ist oft viel Tamtam und nix dahinter. Bei mir ist es aber sehr Anwendungsfallbezogen. Große Dateizahlen eher mit der Shell, bei Schwierigkeiten mit dem Überblick eventuell mit mc. Kleine Adhocaktionen mit Thunar, gerade auch bei Bildern wg. der Vorschau. Auch gut, wg. der Vorschau, aber mit einem schweren Bug behaftet. Habe ich einen Ordner A offen, in dem die jüngste Datei a1 ist und die zweitjüngste a2, und bearbeite a2 und speicher müsste die vorrücken und mit a1 den Platz tauschen. Tut sie aber in der Ansicht nicht. Gehe ich raus aus dem Ordner und wieder rein stimmt die Ansicht (nach Zeit sortiert, neueste oben).
Aber das ist noch nicht alles. Wenn ich jetzt a2, die in Thunar an Position 2 zu liegen scheint, lt. Vorschaubild und Beschriftung, lösche, ist Datei 1 gelöscht. In der Statuszeile (in der eigentlich genug Platz wäre für mtime und Dateigröße - wieso zeigt Thunar das nicht auch an? Ist aber eine andere Frage) steht nämlich a1. WTF? Wenn die Ansicht nicht aktualisiert - ok. Aber dass sie unter der Hand doch umsortiert werden und man falsche Dateien löscht, weiterbearbeitet (mehrere Versionen einer Arbeit gespeichert, trullala!), verschiebt, versendet. Meine Verluste halten sich zwar in Grenzen, wenn ich das richtig bemerkt habe, aber eine fiese Falle. Aber ich muss auch was loben: Gruppen von Dateien mit gleichem Namensmuster mit regulären Ausdrücken umzubenennen, das geht prima in Thunar (wenn man zwischendurch das Fenster aktualisiert). CIMG3419.JPG -
CIMG3507.JPG nach Picknick-3419.JPG Picknick-3419.JPG umbenennen, das ist sehr praktisch.
|
PcDoc2000
Anmeldungsdatum: 4. Februar 2010
Beiträge: 860
Wohnort: Wien
|
Nachdem mich das jetzt auch interessiert hat hab ich das mal versucht nach zu vollziehen mit folgendem Ergebniss: Datei: 1,4GB
Von HDD auf einen nicht all zu schnellen USB Stick kopiert. Jeweils bis die LED vom USB Stick aufgehört hat zu blinken. CP: 5:46 Nemo: 5:25 Von daher wäre CP etwa 6% schneller. Ich hätte nicht gedacht, dass der Unterschied so groß ist, aber zumindest deutlich geringer als bei dir. Wäre wirklich interessant zu erfahren wodurch sich der Unterschied ergibt.
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17552
Wohnort: Berlin
|
PcDoc2000 schrieb: CP: 5:46 Nemo: 5:25 Von daher wäre CP etwa 6% schneller. Ich hätte nicht gedacht, dass der Unterschied so groß ist, aber zumindest deutlich geringer als bei dir.
Für mich sieht das aus wie langsamer. Oder sind das keine min:sec?
|
PcDoc2000
Anmeldungsdatum: 4. Februar 2010
Beiträge: 860
Wohnort: Wien
|
user_unknown schrieb: Für mich sieht das aus wie langsamer. Oder sind das keine min:sec?
Dürfte schön etwas zu spät gewesen sein gestern. Hab die Zeiten vertauscht: Nemo: 5:46 CP: 5:25
|
Vegeta
Anmeldungsdatum: 29. April 2006
Beiträge: 7943
|
Es gibt außer cp noch andere Konsolenprogramme die man miteinander testen könnte, eventuell gibts da auch größere Unterschiede. rsync oder pycp zum Beispiel.
|
sajder
(Themenstarter)
Anmeldungsdatum: 1. März 2017
Beiträge: 19
|
Habe den Fehler entdeckt. Meine USB-Sticks sind in der 'fstab' eingetragen, natürlich mit 'sync' bei USB logisch. Doch hier liegt das Problem. 'sync' verursacht beim Kopiervorgang mindestens doppelt soviel Zeit als wenn ich darauf verzichte. Es folgt ein vergleich zwischen 'sync' und 'async'. 1GB Datei auf USB2-Stick kopiert. (Durchschnitt aus drei Kopiervorgängen) Achtung: Nach jedem Kopiervorgang hab ich den USB2-Stick ausgehängt, da man sich auf das LED nicht verlassen kann. mit 'sync' in der 'fstab':
1m34s cp, mc (Terminal) 2m22s gvfs-copy, gio copy (Terminal) 2m18s Thunar, PCManFM, Nautilus, Caja, emelFM2 4m01s XFE 1m18s rsync 2m16s Nemo 6m49s lfm (Last File Manager) 14m24s ranger
jetzt mit 'async' in der 'fstab', (oder besser noch, USB-Stick nicht in 'fstab' eintragen)
39s cp, mc, Thunar, XFE, rsync, Nemo, usw. (alle gleich schnell)
Der Unterschied ist extrem. Im Terminal kann man ruhig '&& sync' benutzen, das funktioniert, und es bleibt bei 39s. Mein Kopiervorgang ist jetzt Sau Schnell, egal welcher Dateimanager oder im Terminal die Zeiten sind gleich. Ich habe habe meine USBs aus der 'fstab' entfernt, da der Kopiervorgang nur abbremst. Vegeta
Hab ich ausprobiert, solange man USB-Stick NICHT in 'fstab' mit 'sync' einträgt, sind die Zeiten identisch und schnell. PcDoc2000
Ja, Deine Ergebnisse sind geringer. Auf das LED würde ich mich nicht verlassen, besser aushängen. Ich gehe davon aus, dass Du deinen USB-Stick nicht im 'fstab' eingetragen hast!? user_unknown aber mit einem schweren Bug behaftet. Habe ich einen Ordner A offen, in dem die jüngste Datei a1 ist und die zweitjüngste a2, und bearbeite a2 und speicher müsste die vorrücken und mit a1 den Platz tauschen. Tut sie aber in der Ansicht nicht. Gehe ich raus aus dem Ordner und wieder rein stimmt die Ansicht (nach Zeit sortiert, neueste oben). Aber das ist noch nicht alles. Wenn ich jetzt a2, die in Thunar an Position 2 zu liegen scheint, lt. Vorschaubild und Beschriftung, lösche, ist Datei 1 gelöscht. In der Statuszeile (in der eigentlich genug Platz wäre für mtime und Dateigröße - wieso zeigt Thunar das nicht auch an? Ist aber eine andere Frage) steht nämlich a1. WTF? Wenn die Ansicht nicht aktualisiert - ok. Aber dass sie unter der Hand doch umsortiert werden und man falsche Dateien löscht, weiterbearbeitet (mehrere Versionen einer Arbeit gespeichert, trullala!), verschiebt, versendet. Meine Verluste halten sich zwar in Grenzen, wenn ich das richtig bemerkt habe, aber eine fiese Falle.
Also diese Probleme hab ich NICHT. Auf meinem Xubuntu17.10 funktioniert Thunar 1.6.12 so wie es sein soll. Und darüber bin ich froh, jetzt mit den besseren Kopiervorgängen um so mehr.
|
user_unknown
Anmeldungsdatum: 10. August 2005
Beiträge: 17552
Wohnort: Berlin
|
Wer misst misst Mist. ☺ Ich weiß nicht wie gut das Lesen und Schreiben von Dateisystemen und auf solche vom OS gecached wird. Man hat ja eher selten den Fall, die gleiche Datei 2x an die gleiche Stelle zu schreiben, aber eine Datei die schon gelesen wurde, und unverändert im Speicher liegt, muss man nicht nochmal lesen - vielleicht kann sie aus dem Cache genommen werden. Ich spekuliere da aber nur. Jedenfalls sollte man beim Messen nicht nur auf den Mittelwert achten, sondern auch auf größere Unterschiede zw. erster und zweiter Messung. Jetzt will man aber nicht für jede Messung neu booten. Daher würde ich für einen Vergleich eine 1 GB Datei von Platte lesen und messen, und dann mal mit dd, Infile gleich RANDOM wählen und prüfen, das richtige, nämlich das Pseudorandom zu wählen, damit die Zufallszeichenerzeugung nicht das Schreiben ausbremst. Wenn das der Fall ist, dann würde ich die anderen Tests mit dd als Quelle machen. Da cp und nicht dd gemessen werden soll ist die Zeit, die dd braucht, nicht so wichtig, nur für die eigene Geduld und für den Zeitpunkt, wo die Messung beginnen sollte | dd > tmpfile
start messen
cp tmpfile
stop messin
|
Vielleicht genügt es auch, die Dateien zwischendurch einfach mit touch scheinzuaktualisieren, damit sie neu gelesen werden. Also diese Probleme hab ich NICHT. Auf meinem Xubuntu17.10 funktioniert Thunar 1.6.12 so wie es sein soll. Und darüber bin ich froh, jetzt mit den besseren Kopiervorgängen um so mehr.
Ja, ich habe mal nachgesehen, ob ich den Bug (schon)(selbst) gemeldet habe, und einen Bug gefunden, erst 4 Jahre alt, und interessanter Weise nur im Zs.hg. mit Inkscape. Ein Test mit einer txt-Datei zeigte mir auch, dass es kein prinzipielles Thunarproblem ist. Habe dann den Bug zur Sicherheit bestätigt und ein 8 MB Demovideo hochgeladen: https://bugs.launchpad.net/ubuntu/+source/thunar/+bug/1300398/comments/13
|