Sorry, ich komme auch erst jetzt dazu mich zu melden...
Greg schriebJetzt kommt die Nachlieferung von Logdateien:
zu a Der Server ist gemountet, ohne Übertragung von Daten:
zu b: Während ein Backup angestossen wurde. Geringe Dateimengen Übertragung nicht unterbrochen:
zu c: Nachdem der Server unterbrochen ist 33MB von 65MB übertragen.
a)Die ethtool-Ausgaben sind leider bei deiner Karte nicht sehr informativ, bei meiner z.B. gibt es da viel detaillierteren Output. Sie netstat-Ausgaben wären ggf. wohl sinnvoller, da diese AFAIK uniform (also unabhängig was die Netzkarte/Modul an Infos liefert) aufbereitet werden.
Außerdem vermute ich, daß du die Ausgaben für a) und b) "vertauscht" hast, die Werte für tx-/rx-packets lassen das vermuten.
Aus den Ausgaben ist m.E. nichts Auffälliges auszulesen, einziger Wert der etwas raussticht wäre das ungewöhnlich starke Ansteigen von Broadcast-Paketen in der Anzeige bei c). Aber erhöhte Broadcasts sind gerade in CIFS/SMB-Netzwerken nicht zwangsläufig etwas, was auf einen "Fehler" (außer im Design!, scnr) hinweist bzw. mit deinem Symptom ursächlich zusammenhängen mag.
b) Noch was du den Aktionen mit sysctl:
Da hast du offenbar was falsch verstanden.
# sysctl -a |grep -e sack -e timestamp
Hier ändert sich im laufenden Betrieb *nichts*, was ein fortwährendes Wiederholen anders anzeigen würde. Die Werte, die angezeigt werden sind die Default-Werte, mit denen der Kernel/IP-Stack arbeitet. Bei dir nichts anders als bei mir auch, also SACK und Timestamps sind eingeschaltet (1 statt 0).
Was ich damit in meinem Post #4 unten vorschlug war, diese Werte nun mal testweise/temporär zu ändern.
Du hast ja (dein letztes Post mit der DCS_kopie2) ggf. eine Situation, bei der du den rsync-Abbruch reproduzieren kannst. Der Abbruch erfolgt ja *mit* den gesetzten Default-Werten. Mein Vorschlag war/ist nun, nach einem Abbruch einfach einen erneuten Kopiervorgang zu starten, aber diesmal nachdem du als root SACK und Tiemstamps ausgeschaltet hast, eben mit:
# sysctl net.ipv4.tcp_timestamps=0
# sysctl net.ipv4.tcp_sack=0
# sysctl net.ipv4.tcp_dsack=0
Diese Änderungen greifen sofort und bleiben maximal bis zu nächsten Boot (wenn du sie nicht zurück änderst). Es wäre eine Möglichkeit, daß der nun folgende rsync-Lauf nun nicht abbricht. Ich schätze mittlerweile die Wahrscheinlichkeit zwar als gering ein, aber ein Versuch ist es wert...
c) Logfile aufgrund des Posts von tuxnix
Nur damit ich dein Vorgehen auch halbwegs verstehe:
Du kannst also aktuell zwei Situationen "erschaffen":
1. "Zunächst wenn alles funktioniert ohne Serverabbruch"
Hier lässt du rsync deine Doku-Quelle zum Ziel auf dem CIFS-Mount los. Das Ziel enthält aber nun schon nahezu alles, was deine Quelle auch hat, da du die initialen Nutzdaten ja per smbclient/mput schon kopiert hast. rsync muß hierbei also lediglich Sync-Daten austauschen/prüfen, zumindest entnehme ich das deinen Endausgaben (sent 18.94M bytes received 12.49K bytes 113.15K bytes/sec). Hierbei läuft rsync also durch.
2. "Jetzt die Logdatei mit Serverabbruch "
Hier hast du wohl in deinem Quell-Verzeichnis einfach einen Ordner zuätzlich kopiert. Der anschließende rsync-lauf bleibt hängen, da er ja (neue) Nutzdaten übertragen muß und nicht nur Sync-Daten. Und hier ist dann wieder das Bild: der Kopierprozeß startet, läuft aber bleibt nach einer Anzahl von Datenmengen dann hängen.
Das wäre ja eine Arbeitssituation, also "reproduzierbar". Dazu:
a) Die Unterbrechung würde sicher auch passieren, wenn rsync alle Daten initial syncen müßte. Was dir ja ganz am Anfang passiert ist.
b) Das Hängen vom rsync passiert dir aber in der jetzigen Testumgebung nicht nur wenn du eine Kopie des DCS-Verzeichnisses(DCS_kopie2) nutzt, sondern ebenfalls mit jeder anderen, vergleichbaren Menge an Nutzdaten (also ein anderes Verzeichnis)? Nur um auszuschließen das irgendwas mit/in dem DCS-Dir nicht ok wäre.
c) Auf dem Server (Ziel) ist noch genug freier Speicherplatz?
d) Wenn der rsync wieder hängt: Kannst du währenddessen noch (anderes Terminal) auf den CIFS-Mountpoint zugreifen und auch noch Daten schreiben/lesen? Oder ist die cifs-Verbindung ebenfalls "tot", stale ?
e) Baue und installiere dir mal cpdup
Ich habe mir das AUR-Paket mal angeschaut, es baut weiterhin (lediglich die manpage wird nicht richtig behandelt).
https://aur.archlinux.org/packages/cpdup/
manpage: Ändere im PKGBUILD die Zeile:
install -Dm 644 cpdup.1 "$pkgdir"/usr/share/man/man1
nach
install -Dm 644 cpdup.1 "$pkgdir"/usr/share/man/man1/cpdup.1
Das hätte den Vorteil, eben rsync als möglichen "Verursacher" (erneut, einmal hast du es ja schon durch smbclient/mput getan) auszumachen und eben nicht ursächlich das Netzwerk/Win-Server/Dateisysteme an sich .
Ich würde mit cpdup einfach dein (Quell)Doku-Dir in ein neues Ziel im cifs-Mount syncen lassen, also alles an Daten nochmal (initial) übertragen. Vor allem deswegen, da ich ad hoc nicht weiß ob cpdup ein Verhalten ermöglicht was du mit deinem rsync-Paramater --numeric-ids erreichen willst. Das also dann nach dem Syncen nochmal nachprüfen, aber AFAIK hat cpdup in seinen Default-Einstellungen schon "sinnvollere" Werte als rsync.
Ein möglicher Aufruf bei dir wäre also:
cpdup -vvI /mnt/Doku/ /mnt/privat-fs/Doku-test/
(oder für weniger verbose-Output)
cpdup -dI /mnt/Doku/ /mnt/privat-fs/Doku-test/
Das Ziel-Verzeichnis mnt/privat-fs/Doku-test/ wird angelegt sofern nicht vorhanden. Ansonsten arbeitet cpdup defaultmäßig ähnlich wie rsync, anhand von Dateigröße/Zeitstempel wird geprüft ob Dateien übertragen/gesynct/gelöscht werden müssen.