Login
Newsletter
Werbung

Thema: Kopieren von Dateien unter Linux könnte schneller werden

63 Kommentar(e) || Alle anzeigen ||  RSS || Kommentieren
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von Developer am Fr, 31. Mai 2019 um 19:32 #

Der hat auch einstellbare Puffergrösse

0
Von Calabi-Yau am Sa, 1. Juni 2019 um 00:17 #

Das Kopieren auf der Festplatte geht bereits jetzt recht schnell, so dass Verbesserungen für den User wohl marginal sein dürften. Wird er wohl kaum spüren. Das Kopieren auf USB-Sticks (vermutlich eine der häufigsten Kopiervorgänge) hängt jedoch hauptsächlich vom Stick selbst ab. Mir wäre ehrlich gesagt eine automatische Verifizierung mithilfe der Prüfsumme wichtiger. Ich will sichergehen, dass die Dateien korrekt auf dem Ziellaufwerk ankommen. Bei Windows ist FastCopy genial, unter Linux sucht man jedoch so eine Software leider vergeblich. Krusader bietet hier vermutlich noch die eleganteste Lösung, ist aber dennoch vergleichsweise umständlich, weil zusätzliche Klicks notwendig sind.

0
Von Atalanttore am Sa, 1. Juni 2019 um 15:24 #

Speziell beim Kopieren/Verschieben auf bzw. von Samba-Freigaben funktioniert die Fortschrittsanzeige (unter Gnome 3 / KDE 5) nicht mehr zuverlässig.

Der Kopieren/Verschieben-Dialog von Windows, in dem es sogar ein Geschwindigkeitsdiagramm gibt, funktioniert bei Netzlaufwerken um Welten besser.

1
Von Crass Spektakel am So, 2. Juni 2019 um 06:31 #

Vor vielen Jahren mußte ich eine grosse Anzahl kleiner Dateien kopieren.

Interessanterweise zeigte sich daß fast auf allen Plattformen eine deutliche Beschleunigung zu sehen war wenn man die Dateien nach inodes sortiert kopierte - selbst wenn man das Erfassen und Sortieren des inodes mitrechnete.

Die Programmierer von tar und scp lehnten Verbesserungen dahingehend grundsätzlich ab, 20% mehr Leistung wären keine dahingehenden komplexen Anpassungen wert. Der Programmierer von rsync war durchaus angetan meinte aber daß da aufgrund der anderen Herangehensweise von rsync ein Rattenschwanz von Sonderfällen dran hängt.

  • 1
    Von 1ras am So, 2. Juni 2019 um 15:22 #

    Das wird mit den Zugriffszeiten der Festplatten zu tun gehabt haben, Inodes die direkt hintereinander liegen verursachen geringere Zugriffszeiten.

    Heutzutage mit SSD dürfte es hingegen relativ egal sein.

0
Von schmidicom am Mo, 3. Juni 2019 um 08:44 #

Ob das die Devs der GNU Coreutils überhaupt interessiert? Die Bitte nach einer Fortschritts-Anzeige bei cp und mv wurde ja auch laufend ignoriert.

  • 1
    Von cyberpatrol am Mo, 3. Juni 2019 um 12:08 #

    Die Bitte nach einer Fortschritts-Anzeige bei cp und mv wurde ja auch laufend ignoriert.
    Und das ist auch gut so!

    Eine Fortschrittsanzeige machts nämlich im Allgemeinen noch sehr viel langsamer, schon allein wegen der ganzen Berechnungen (Anzahl und Größe der Dateien, Anzahl der schon geschriebenen und noch zu schreibenden Bits und Dateien und dann noch das Gemälde des Fortschrittbalkens).

    Und beim Verschieben innerhalb desselben Dateisystems sowieso völliger Overkill.

    Das ist übrigens auch ein Grund dafür, warum ich lieber mit cp und mv als mit irgendeinem grafischen Dateimanager kopiere und verschiebe. Geht viel schneller.

0
Von Janko Weber am Mo, 10. Juni 2019 um 21:53 #

Ich finde schon den ersten -fettgedruckten- Absatz suspekt.
Es könnte doch wohl mal grundsätzlich immer alles schneller sein. Und wenn man dann das Problem auf die Dateimanager schiebt: warum nicht einfach einen anderen verwenden. Gehen diese Kernel-Entwickler davon aus daß ALLE Gnome 3 oder KDE 5 und die dafür vorgesehenen Dateimanager verwenden? Nicht alle Linux-Nutzer sind Idioten!


MfG Janko Weber

Pro-Linux
Traut euch!
Neue Nachrichten
Werbung