staging.inyokaproject.org

Hallo Forum,

seit einiger Zeit habe ich im Dolphin bei Aktionen im Dateisystem (Verzeichnis wechseln, neues Verzeichnis erstellen, Dateien kopieren / verschieben) teilweise sehr lange Wartezeiten, nur sehe ich keine Ursache dafür. Wie könnte ich den Fehler eingrenzen?

In meinem PC gibt es sowohl M.2, SSDs, und HDDs. Dabei sind nicht alle auf der obersten Verzeichnisebene / eingeordnet, sondern teilweise untereinander geordnet:

• / M.2

• /home HDD

• /home/user HDD

• /home/user/Mail SSD

Könnte diese Schachtelung eine Ursache dafür sein?

Viele Grüße Markus

PS: Die Mischung (M.2, SSD, HDD) rührt daher, dass ich den PC mit der Zeit erweitert habe.

Hallo amibobo, ich würde Dir vorschlagen, das Du zuerst testest von WO nach WO sich Verzögerungen ergeben.

Das würde man so probieren…

Verwende eine ext.USB-HDD und kopiere dorthin eine grosse Datei, z.B. 1GB… dann kopierst Du diese Datei im Terminal mit dem Befehl cp an das erste Ziel und misst die Zeit.

Danach benennst Du diese Datei auf dem ext.USB-HDD um und machst den Vorgang mit dem nächsten Ziel usw..

Hast Du alle Zeiten, dann machst Du das gleiche mit kopieren ZWISCHEN Deinen einzelnen Zielen - ebenfalls immer die Quelle umbenennen.

So kommst Du dahinter ob es mit der Verschachtelung zu tun hat.

Sind alle schnell, dann ist es ein Problem in Deiner GUI… da wüsste ich aber keine passende Variante, den wir verwenden nur MATE und XFCE Desktops.

BYE HS

Könnte diese Schachtelung eine Ursache dafür sein?

Theoretisch könnte das sein, aber ich glaube nicht, dass das großen Einfluss hat.

Zunächst sollte man Kopiere und Verschieben getrennt behandeln, denn beim Kopieren muss immer kopiert werden, bei Verschieben gibt es Ausnahmen.

Bei Linux gilt "Alles ist eine Datei". Das bedeutet, Verzeichnisse sind auch nur Dateien. Wenn jetzt eine Datei innerhalb des selben Dateisystems verschoben wird, werden nur die entsprechenden Datenblöcke in den Verzeichnis-Dateien umkopiert. Die eigentlichen Daten auf der Platte werden dann nicht angefasst!

Sind Quelle und Ziel auf unterschiedlichen Geräten, müssen die Daten immer kopiert werden. Und wenn dann ein Mountpunkt auf einem anderen Gerät liegt, können auch mehr als zwei Verzeichnisdateien beteiligt sein. Die Geschwindigkeit wird durch das langsamste beteiligte Gerät bestimmt. Ausreichend Arbeitsspeicher (Cache) könnte das aber abmildern.

Könnte diese Schachtelung eine Ursache dafür sein?

Ich würde dieses Konstrukt testweise auflösen (die mounts deaktivieren) und dann schauen, ob der Fehler weg ist.

• Wenn nein, riecht es nach Problem im Benutzerprofil. Dann zuerst mit einem neu angelegten Benutzer testen. Ist es dann auch noch so, die Ursache weiter im Betriebssystem oder in der eigenlichen Anwendung suchen.

• Wenn ja, die mounts Schritt für Schritt wieder aktivieren uns schauen, was dabei herauskommt.

Nach jeder Änderung den Rechner am besten komplett neu starten. Für den Fall der Fälle immer ein passendes Live-System bereithalten, um im Notfall von außen eingreifen zu können.

Hallo Leute,

vielen Dank für eure ersten Ideen und ich sollte nach langen Tagen nichts mehr posten, da vergesse ich immer so viel:

Hallo amibobo, ich würde Dir vorschlagen, das Du zuerst testest von WO nach WO sich Verzögerungen ergeben.

Wichtiger Punkt: Oft sind es Datei- oder Verzeichnisaktionen auf der selben Hardware, oft /home/user HDD

Ich dachte auch schon daran, ob evtl. beim verzeichnistechnischen Wechsel auf eine andere Hardware diese aus dem Standby erwachen muss, aber nein, oft bin ich ja im Home-Verzeichnis aktiv und das ist – mit Ausnahme von /Mail – die selbe HDD. Auch das Erstellen eines neuen Verzeichnisses dauert teilweise 30 Sek.

Verwende eine ext.USB-HDD und kopiere dorthin eine grosse Datei, z.B. 1GB… dann kopierst Du diese Datei im Terminal mit dem Befehl cp an das erste Ziel und misst die Zeit.

Die Datensicherung über die Konsole mache ich auf ebenso eine externe USB-HDD, dort habe ich nicht den Eindruck, dass es da besonders lange dauert. Hier die Zusammenfassung der Komplettsicherung gerade:

Number of files: 3.104.826 (reg: 2.909.381, dir: 148.659, link: 46.786)
Number of created files: 40.119 (reg: 39.818, dir: 286, link: 15)
Number of deleted files: 32.765 (reg: 32.711, dir: 42, link: 12)
Number of regular files transferred: 44.008
Total file size: 2.210.673.662.806 bytes
Total transferred file size: 2.120.619.815 bytes
Literal data: 1.791.627.201 bytes
Matched data: 0 bytes
File list size: 88.594.722
File list generation time: 93,627 seconds
File list transfer time: 0,000 seconds
Total bytes sent: 1.882.427.828
Total bytes received: 4.683.373

sent 1.882.427.828 bytes  received 4.683.373 bytes  2.764.998,10 bytes/sec
total size is 2.210.673.662.806  speedup is 1.171,46
rsync warning: some files vanished before they could be transferred (code 24) at main.c(1338) [sender=3.2.7]