RAM1447
Anmeldungsdatum: 21. April 2006
Beiträge: 24
|
Ich nutze xubuntu 18.04.3 und mache die Beobachtung, daß ein Datentransfer zu einem über das WebDAV (davs) angesprochene und mit fuse (gio) eingehängten Dateisystem einschläft und auch nicht wieder aufwacht. Verbindung wird hergestellt mit „# gio mount davs://<Telekomcloud>“ - es macht keinen Unterschied, ob Kommando, „Thunar“ Adressleisteneingabe oder „gigolo“. Verbindung wird etabliert und ich kann über Dateiexplorer „Thunar“ oder Kommandozeile prinzipiell Daten auflisten, hoch- und herunterladen. Wenn ich (gefühlt) mehr als 10-40MB in die Cloud hochladen will wird die Transferrate nach ein paar MBs langsamer bis der Transfer komplett aufhört. Dieser Status ändert sich nicht mehr und nur durch einen Verbindungsabbruch und neu Verbinden kann ich wieder auf die Cloud zugreifen. Die Cloud hat kein Kapazitätsproblem. Das Verhalten ist reproduzierbar und zeigt sich auch wenn ich auf mein lokales NAS per WebDAV auf ein mit fuse eingehängtes Dateisystem „größere“ Datenmengen kopiere. Mein Verdacht geht in Richtung fuse da das Phänomen nicht auftritt, wenn ich einen entsprechenden fstab Eintrag erstelle (Beispiel: „https://webdav.magentacloud.de /home/portable/mnt/magentacloud davfs user,noauto 0 0“) und das Dateisystem mit mount einhänge – was ich eigentlich nicht machen möchte. Thunar kann ich auch ausschließen, da ein Kopieren über Kommandozeile zum entsprechenden Verzeichnis in „/run/user/<UID>/gvfs/…“ auch einschläft. Hat sonst jemand dieses Phänomen schon gehabt oder kennt es? Hat jemand einen Ansatz/eine Idee wie ich das Problem lösen kann?
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
Hallo! Du könntest versuchen, ob die Option use_locks 0 in der Konfiguration hilft - und bitte beim Test aufpassen und zunächst nur mit einem User testen! Siehe davfs2.conf.
|
RAM1447
(Themenstarter)
Anmeldungsdatum: 21. April 2006
Beiträge: 24
|
Hallo ChickenLipsRfun2eat, vielen Dank für die schnelle und kompetente Antwort. Das scheint tatsächlich zu helfen!! Mein NAS ist mit diesem Setting auch viel schneller.
Der Cloudspeicher funktioniert damit auch viel stabiler. Vielen Dank nochmal für deine Hilfe !! Grüße, RAM1447 PS: Leider verstehe ich nicht warum diese Einstellung etwas bewirkt. Ich dachte, davfs2 wäre ein Treiber, der genutzt wird wenn man mit dem "mount" Befehl arbeitet und hat nichts mit "gio/gvfs/fuse" zu tun. Muß ich nochmal darüber nachdenken.
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
RAM1447 schrieb: PS: Leider verstehe ich nicht warum diese Einstellung etwas bewirkt.
Normalerweise wird beim Bearbeiten einer entfernten Datei ein lock (Sperre) gesetzt, damit nicht zwei Verbindungen zeitgleich die selbe Datei bearbeiten können. Mal vereinfacht ausgedrückt:Wenn ein solches lockfile hängen bleibt, bspw. durch einen nicht registrierten Verbindungsabbruch, etc. dann bist du in der Dauer-Warteschleife und es "hängt", da das System noch auf die Freigabe von der vorherigen Verbindung wartet, die aber nie kommt. Natürlich birgt diese Methode auch die Gefahr, dass sich mehrere Verbindungen in die Quere kommen, daher der Link auf die Manpage ☺
|
RAM1447
(Themenstarter)
Anmeldungsdatum: 21. April 2006
Beiträge: 24
|
Ich hatte wirklich gehofft das Problem los zu sein und mein erster Test war wohl nicht sorgfältig genug.
Es scheint aber nur nicht mehr so schlimm.
Wenige große Dateien lassen sich nun ziemlich stabil kopieren aber viele kleine Dateien sind immer noch ein Problem.
Hier habe ich weiterhin das oben beschriebene Verhalten. Bin also immer noch auf Lösungshilfe angewiesen. Sorry, RAM1447
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
Steht denn etwas über die Abbrüche in den Journaleinträgen? Starte bitte mal Thunar aus einem Terminalfenster heraus, vielleicht spuckt der passende Meldungen aus, die uns das Problem eingrenzen lassen. Ausgaben bitte im Codeblock posten.
|
RAM1447
(Themenstarter)
Anmeldungsdatum: 21. April 2006
Beiträge: 24
|
Alles nicht so einfach ChickenLipsRfun2eat.
"#journalctl" hat keine relevanten Einträge Thunar läuft nicht in der Shell sondern verabschiedet sich in den Hintergrund
| ram@umin64-vm1:~$ thunar
ram@umin64-vm1:~$ ps -ef|grep thun
ram 1891 1758 0 19:44 ? 00:00:00 /usr/lib/x86_64-linux-gnu/xfce4/panel/wrapper-1.0 /usr/lib/x86_64-linux-gnu/xfce4/panel/plugins/libthunar-tpa.so 13 20971565 thunar-tpa Papierkorbregler Papierkorb anzeigen
ram 9109 8983 0 20:01 pts/1 00:00:00 grep --color=auto thun
ram@umin64-vm1:~$
|
Problem tritt auch auf wenn ich ohne Thunar kopiere:
ram@umin64-vm1:~$ gio mount davs://<USER>@webdav.magentacloud.de
Bitte Passwort für User Auth eingeben
Password:
ram@umin64-vm1:~$ rsync -rcv --progress /home/ram/test/Hintergründe /run/user/1000/gvfs/dav\:host\=webdav.magentacloud.de\,ssl\=true\,user\=<USER>/WebDavTests/
sending incremental file list
Hintergründe/
Hintergründe/07958e44-8340-4784-bdd3-2c3671d64728.jpeg
125,840 100% 88.76MB/s 0:00:00 (xfr#1, to-chk=103/105)
Hintergründe/10f3efe3-c03b-4b04-b5a9-df4f5460a135.jpeg
91,108 100% 193.42kB/s 0:00:00 (xfr#2, to-chk=102/105)
...
Irgendwo zwischen 8 und 35 von 105 Übertragungen ist normalerweise Schluß Ein "#strace -p <PID von rsync>" liefert nur die info, daß ein Timeout auftritt: ...
select(4, [3], [], [3], {tv_sec=60, tv_usec=0}) = 1 (in [3], left {tv_sec=58, tv_usec=249646})
read(3, "\4\0\0k'\0\0\0", 32768) = 8
select(4, [3], [], [3], {tv_sec=60, tv_usec=0}) = 1 (in [3], left {tv_sec=58, tv_usec=177326})
read(3, "\4\0\0k(\0\0\0", 32768) = 8
select(4, [3], [], [3], {tv_sec=60, tv_usec=0}) = 0 (Timeout)
select(4, [3], [], [3], {tv_sec=60, tv_usec=0}) = 0 (Timeout)
... Hast du noch eine geniale Eingebung? Vielen Dank schon jetzt für die Mühe und Geduld
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
RAM1447 schrieb: Hast du noch eine geniale Eingebung?
Sowas habe ich leider nie. Aber ich versuche das jetzt mal nachzubauen und richte mir eine Telekom-Cloud ein. Ich weiß nur, dass die relativ streng bei timeouts sind, wenn man bspw. über ssh mit seinem Webspace verbunden ist (Hab ich da noch, damals gab es keine Cloud ☺ ). Beim Kopieren war das allerdings nie ein Problem, nur ohne Eingabe flog man schnell raus. Nachtrag1: Ich habe gerade 1928 Dateien in 785 Ordnern mit einer Größe von 49,9MiB erfolgreich ohne weitere Einstellungen kopiert. Ebenfalls über davs (bzw. in meinem Fall webdavs, da Plasma) Den nächsten Test mache ich dann mal mit xubuntu, da muss ich nur ne VM für einrichten. Werde die Infos dann nachreichen. Nachtrag2:
sent 1,274,400,243 bytes received 366,447 bytes 158,661.61 bytes
total size is 1,272,452,596 speedup is 1.00
Habe unter der Xubuntu Session per gio mount davs und rsync 1,3G Daten (18561 Dateien, 2427 Ordner) rübergeschaufelt. Nicht schnell, aber ohne Probleme. Daher schließe ich hier mal einen Fehler aus. Hast du denn generell Netzwerkabbrüche oder Neuverbindungen? Ggf. kannst du den Vorgang ja mal mittels netstat -tualpenc beobachten. Dort sollten die (standardmässig bis zu 5) Verbindungen ersichtlich sein. Eventuell Powermanagement der WLAN-Karte oder andere Energiespareinstellungen, die die Ursache sein könnten? Auch mal im Router gucken, ob dieser Neuverbindungen im Log anzeigt, im Speedport wäre das unter "Systemmeldungen" ersichtlich.
|
RAM1447
(Themenstarter)
Anmeldungsdatum: 21. April 2006
Beiträge: 24
|
Verbindungsprobleme kann ich ausschließen. Auch bin ich per LAN Kabel verbunden. 1. Kopieren auf ein mit "#gio mount" eingehängtes Dateisystem kommt bei mir immer zum Stillstand - egal, ob ich die Telekomcloud oder mein lokales NAS per WebDav einhänge und wie ich kopiere (Kommando oder GUI) 2. Nutze ich statt "#gio mount" den davfs2 Treiber - also fstab Eintrag und "#mount" Kommando wie im "WebDav Wiki" beschrieben funktioniert das kopieren auf alle Arten - sowohl Cloud als auch NAS. Diese Option wollte ich nicht nutzen, da ich Anpassungen (fstab, user-group Assignment) machen muß und Thunar immer wieder Einfriert solange nicht alle Daten übertragen sind. 3. Verbinde ich mich per "gio mount ssh://<NAS>" funktionieren Transfers schnell und stabil - leider komme ich so nicht an meine Cloud Die bisherigen Tests liefen in VMs auf einem Windows Laptop. Ich habe auch eine OpenSUSE xfce VM installiert, die aber genauso reagiert. Tests auf einem nativen LINUX PC im gleichen Netzwerk zeigten das selbe Verhalten. Nach deiner Aussage, daß es bei dir funktioniert muß ich wohl bei mir weiter suchen und kann mich nur für deine Bemühungen bedanken. Danke dir, RAM1447
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
RAM1447 schrieb: 3. Verbinde ich mich per "gio mount ssh://<NAS>" funktionieren Transfers schnell und stabil - leider komme ich so nicht an meine Cloud
Wieso nicht? Vielleicht kommen wir darüber an den Fehler, da ich ja genau so kopiert hatte. Und im Post vorher hast du geschrieben, dass es dabei auch Probleme gibt. Wie hast du diese behoben?
Die bisherigen Tests liefen in VMs…
Bei mir war es auch eine VM, spielt dabei weniger eine Rolle, wenn der Host nicht die Netzwerkverbindung selbst einschränkt. Der native Test war auch mit Xubuntu 18.04.3?
Nach deiner Aussage, daß es bei dir funktioniert muß ich wohl bei mir weiter suchen und kann mich nur für deine Bemühungen bedanken.
Kein Problem. Ich bin sowieso gerade meine VMs am aussortieren und werde die TCom-Cloud schon irgendwie einbauen. Kostet ja nix 😉
|
RAM1447
(Themenstarter)
Anmeldungsdatum: 21. April 2006
Beiträge: 24
|
ChickenLipsRfun2eat schrieb: RAM1447 schrieb: 3. Verbinde ich mich per "gio mount ssh://<NAS>" funktionieren Transfers schnell und stabil - leider komme ich so nicht an meine Cloud
Wieso nicht? Vielleicht kommen wir darüber an den Fehler, da ich ja genau so kopiert hatte. Und im Post vorher hast du geschrieben, dass es dabei auch Probleme gibt. Wie hast du diese behoben?
gar nicht - ich nutze statt Protokoll davs "#gio mount davs://<NAS>" eben "#gio mount ssh://<NAS>" - die Telekomcloud lät aber nur "davs" zu. Die bisherigen Tests liefen in VMs…
Bei mir war es auch eine VM, spielt dabei weniger eine Rolle, wenn der Host nicht die Netzwerkverbindung selbst einschränkt. Der native Test war auch mit Xubuntu 18.04.3?
Richtig - nativ ist auch 18.04.3 - das mit dem Windows habe ich nur erwähnt da die Firewall und Intrusion Detection meiner Meinung nach ein "Eigenleben" entwickeln und die kontrollieren schließlich die physische LAN Schnittstelle. In diesem Fall scheint das aber nicht von Bedeutung da es nativ das gleiche Fehlerbild ergibt. Nach deiner Aussage, daß es bei dir funktioniert muß ich wohl bei mir weiter suchen und kann mich nur für deine Bemühungen bedanken.
Kein Problem. Ich bin sowieso gerade meine VMs am aussortieren und werde die TCom-Cloud schon irgendwie einbauen. Kostet ja nix 😉
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
RAM1447 schrieb: gar nicht - ich nutze statt Protokoll davs "#gio mount davs://<NAS>" eben "#gio mount ssh://<NAS>" - die Telekomcloud lät aber nur "davs" zu.
Sorry, da habe ich nicht richtig gelesen. Kannst du das mal mit einem Live-Medium testen? Eventuell auch mal ein Kubuntu (Dolphin - Netzwerk - Hinzufügen öffnet knetattach )? Dann könnten wir zumindest irgendeine™ lokale Konfiguration ausschließen.
|
RAM1447
(Themenstarter)
Anmeldungsdatum: 21. April 2006
Beiträge: 24
|
Das kann ich machen - wird aber ziemlich sicher nichts bringen. Ich habe in meiner Verzweiflung auch schon ein OpenSUSE Tumbleweed XFCE installiert das sich auf meinem Laptop auch so verhält.
Netzwerk kann ich ausschließen - wenn ich Daten per Android, Windows oder auch über die Cloud- oder NAS-Browseroberfläche verschiebe/kopiere funktioniert das wie es soll.
Zum Test setze ich jetzt ein KUBUNTU auf und versuche mich an deinen Vorschlägen. Da ich kein kubuntu iso habe nehme ich das "ubuntu1804mini.iso" und wähle zum Installieren "KUBUNTU-FULL" aus.
Sobald ich die Tests gemacht habe melde ich mich wieder.
Danke für dein Durchhaltevermögen.
Grüße,
RAM1447
|
ChickenLipsRfun2eat
Anmeldungsdatum: 6. Dezember 2009
Beiträge: 12067
|
RAM1447 schrieb: Zum Test setze ich jetzt ein KUBUNTU
Brauchst du nicht. Da reicht die Live-CD aus. Aber natürlich darfst es gerne installieren ☺
|
RAM1447
(Themenstarter)
Anmeldungsdatum: 21. April 2006
Beiträge: 24
|
Die gute Nachricht zuerst: Deine Variante mit " Kubuntu (Dolphin - Netzwerk - Hinzufügen)" funktioniert - ich habe 244,8 MiB, 292 Dateien, 17 Ordner ohne Probleme in meine Cloud bekommen !!
Was hier wie gemounted wurde ist mir leider unklar: weder "# gio mount -l" noch "# mount" zeigt mir hier den passenden Eintrag. Es scheint also weder per fuse noch per davfs2 Treiber eine Verbindung hergestellt zu werden. Kannst du für mich Licht ins Dunkel bringen? Ein Versuch mit "# gio mount webdavs://USER@webdav.magentacloud.de" scheiterte mit "Datenträger unterstützt Einhängen nicht" - mir scheint, meine Art der Kubuntu-Installation hat nicht alle benötigten Pakete installiert. Weißt du zufällig, was ich nachinstallieren muß? Wie werde ich den die Netzwerkverbindung zu meiner Cloud wieder los - also wie schließe ich die Verbindung wieder? Nachtrag:
Mir ist gerade wieder eingefallen das das "g" in gio oder gvfs für gnome steht - vielleicht gibt es gar kein Pendant in KDE
|