Du bist nicht angemeldet.

Eine Antwort schreiben

Schreibe deinen Beitrag und versende ihn
Beitragsoptionen
Deine Antwort

Zurück

Themen-Übersicht (Neuester Beitrag zuerst)

Greg
05.06.2019 11:31:04
GerBra schrieb:

.... das Zeuch im Kaffee wirkt endlich. Obwohl mir gesagt wurde daß gerade die rosa Pillen keine Spätfolgen auslösen...

Au mann, wegen mir bekommst du noch nen Herzkasper und einen rosa Pillenknick. Wie kann ich das wieder kitten?

Aaaaber ich habs endlich raus an was es liegt.
Ein Downgrade auf kernel 5.1.2 , reboot, mounten des Servers und Backup starten verursacht wieder eine Serverunterbrechung.
Da seid Montag alles wieder funktioniert, lief bereits der kernel 5.1.6.
Heute nochmal ein update durchgeführt mit Kernel 5.1.7 läuft immer noch alles tadellos.
Alles Bestens!!

GerBra, du kannst wieder locker lassen.
Schard, am Besten du schliesst das Ding hier damit Gerbra nicht auf dumme Gedanken kommt und noch den Löffel abgibt. Das wäre ein schwerer Verlust hier.

Nochmals ein herzlichstes Dankeschön !!

Wie immer...
Gruß aus DN
Greg

GerBra
04.06.2019 22:16:06
Greg schrieb:

Noch habe ich beim IT-Mann kein Feedback gegeben. Der Gute soll auch wissen was sich da tut.

Da mußt du halt runter in den Keller, der ist ja bei der Party.

Ist es nicht einsam im Büro?
Nur Du.
Und der Typ, der immer da sitzt.
Da er schon jahrelang am rektalen Zugangsalgorithmus zur Geschäftleitung programmiert.

;-) Ich könnte heute stundenlang so weitermachen, das Zeuch im Kaffee wirkt endlich. Obwohl mir gesagt wurde daß gerade die rosa Pillen keine Spätfolgen auslösen...

Greg
04.06.2019 21:57:31

Mensch GerBra,
ich brech nieder.
Was es für Phänomene all gibt. Ihr Netzwerker seid schon komisch.
Mal sehen wies morgen ist. Vielleicht wieder wie vorher..(Grins). Dann geht der ganze Zinnober von vorne los.
Ich habe übrigens mal noch versucht vers=2.0  und 2.ähh nach Manpage halt durchprobiert. Hat aber nicht geklappt. Es muß immer vers=1.0 sein. Hätt ja sein können, dass Jemand am Server geschraubt hat.
Ein erheblich größeres Verzeichnis habe ich auch schon kopiert. Auch das hat geklappt. Wie ich schon zu Anfangs geschrieben hatte, ich weiß leider nicht seid wann die Probleme auftauchten.
Noch habe ich beim IT-Mann kein Feedback gegeben. Der Gute soll auch wissen was sich da tut.

Ich wünsch dir immer eine Handbreit Asphalt unterm Pneu!!

Gruß aus DN
Greg

schard
04.06.2019 21:50:17

Puh! GerBra sei Dank.

GerBra
04.06.2019 21:30:17

@ schard: Keine Angst, von meinen wirklich wichtigen Beiträgen habe ich ein Backup (Kopierpuffer sei Dank!, wenn schon die Browserhistorie versagt)... Kann ich also nochmal posten.
Don't drink and root... scnr ;-)


@Greg:
//Edit: leicht abgewandelt, geändert:

Greg schrieb:

...Ich glaub ich spinne, es läuft einwandfrei durch.
...
Alles sehr merkwürdig. Sollte etwa der ganze Aufwand umsonst gewesen sein? Schade um deine Mühen GerBra!! Damit wäre der eigentliche Fehler bzw. Fehlerbeseitigung unbekannt.

Ach, mir fallen da auf Anhieb mindestens drölfzig Moglichkeiten ein:
- meine magischen Fernheilungskräfte (legendär!)...

- Netzpsychose (kommt gerade bei älteren Netzwerken häufig vor)...

- Sonnenwinde (DER Klassiker aus der BOfH-Werkzeugkiste)...

- irgend so ein Gender-Change-Dingens, dein Kabelnetzwerk möchte mal ein WLan sein...

- so'n gaaaanz fieser Algorithmus, der in Monaten zuschlägt die auf "i" enden - aber nur wenn month.name.length <= 3 ...

- Böse Mächte (aka Net-Stormtroopers) haben sich gegen DICH verbündet, um DICH langsam aber sicher in den ẂAhnsInn zu treiben (ist M.I.R auch passiert, hehe!)

- Der Server hat den Kram den du da schon tagelang sendest mittlerweile auswendig gelernt. Da kommt nur noch ein gelangweiltes Gähnen: Ach, DER schon wieder mit seinem Doku-Kram, winken wir's durch... Das ist Windows AI!

- Sämtliche deiner Arbeitskolleg*innen feiern seit gestern Abend eine wilde, orgiastische Party (sabber!) bei euch im Keller, du bist der einzige Trottel der noch arbeitet. Ergo: Läuft bei dir...
Merke: Die Anzahl von rsync Fehlern im Netzwerk steht in reziproger Koalition zur Ab- oder Zunahme von Youtube-Katzenvideos.

Such dir was aus.

Ansonsten, so halbwegs ernsthaft: Kann, wie du sagst, alles sein. Ggf. auch irgendeine Komponente die neu gestartet wurde (Switch z.B.). Kannst ja mal versuchen, das ganze Doku-Dir an ein neues Ziel zu syncen, ob der momentane Zustand auch das verkraftet.

Aber im Ernst: Mir gefallen meine obigen Erklärungen viel besser, v.a. da diese auf aktuellen technisch-wissenschaftlichen Analü..., Analogisi,....emmm, Untersuchungen beruhen.

Ansonsten haben wir mit dem Thread doch wenigstens so getan, also ob wir wissen was wir tun und über was wir reden. Gutes Forum... Haben auch alle das Quanta-Abitur hier. Bringt uns bestimmt ein paar Punkte beim Google-Ranking.

Greg
04.06.2019 09:59:36
GerBra schrieb:

..Jetzt könntest du nochmal prüfen, welche der drei Einstellungen nun ausschlaggebend wären:..

Na klar, das werde ich jetzt machen.
Zunächst die Werte auf die Standardeinstellungen zurücksetzen. Damit müßte es dann wieder hängen...

net.ipv4.tcp_timestamps = 1
[root@zat264 gl]# sysctl -a |grep -e sack -e timestamp
net.ipv4.tcp_comp_sack_delay_ns = 1000000
net.ipv4.tcp_comp_sack_nr = 44
net.ipv4.tcp_dsack = 1
net.ipv4.tcp_sack = 1
net.ipv4.tcp_timestamps = 1
net.netfilter.nf_conntrack_timestamp = 0

...Ich glaub ich spinne, es läuft einwandfrei durch.
Was wurde gemacht?
Gestern ein update durchgeführt und danach hatte ich wie du es vorgeschlagen hast die Werte verändert siehe Post vorher. Wieder ein Backup gemacht. Es lief dann alles einwandfrei durch. Damit habe ich geglaubt, es läge an den neuen Einstellungen.
Heute die Werte auf die Standardwerte belassen, reboot und ein Backup gemacht. Müßte ja wieder hängen. Lief aber einwandfrei durch. (grummel).
Jetzt gibt es 3 Möglichkeiten die den Fehler beseitigt haben könnten.
Entweder das Update unter Anderem den neuesten Kernel, filesystem oder die IT-Leute haben etwas verändert oder die bei netapp haben etwas verändert.
Alles sehr merkwürdig. Sollte etwa der ganze Aufwand umsonst gewesen sein? Schade um deine Mühen GerBra!! Damit wäre der eigentliche Fehler bzw. Fehlerbeseitigung unbekannt.
Bin mal gespannt wie lange das so bleibt.

Gruß aus DN
Greg

GerBra
03.06.2019 13:07:31
Greg schrieb:

Meinen herzlichsten Dank nochmal für deine ausführlichen Erklärungen und der vielen Arbeit die da hintersteckt.

Freut mich auch, v.a. da ich an das Ändern der IP-Einstellungen eigentlich keine großen Erwartungen mehr hatte.

Jetzt könntest du nochmal prüfen, welche der drei Einstellungen nun ausschlaggebend wären:
Verwendung von Timestamps in IP-Paketen haben eine ganz andere Auswirkung als das Abstellen von SACK. Ich tippe mal auf SACK als "Wunderschalter", also teste ruhig mal mit timestamps wieder auf 1.
Wenn es SACK ist, dann würde ich auch gerne noch wissen ob nun sack oder dsack die entscheidende Option ist, die abgestellt werden muß für euer Netzwerk/Server (Wobei ich mir bei dsack noch weniger über die detaillierte Bedeutung klar bin, //edit bzw. ob diese beiden überhaupt getrennte Einstellungen ermöglichen).

Gruß vom demnächst schnakenverseuchten Mittelrhein (weil die Spritzhubschrauber kaputt sind, sind wohl verkappte Regierungsflugmaschinen <g>)

//Edit:
Wie du ja evtl. weißt kannst du sysctl-Werte ja auch dauerhaft anders abspeichern, siehe
man sysctl
man sysctl.conf
Allerdings würde ich ggf. davon Abstand nehmen, sondern zur Not halt diese mit in dein Backupskript reinpacken, und nach dem Transfer ggf. wieder auf die Defaultwerte zurücksetzen.

Greg
03.06.2019 12:56:55

Hallo GerBra,
du bist der Held des Tages, ach was des Jahres!!!
Es klappt.
vor Änderung:

# sysctl -a |grep -e sack -e timestamp
net.ipv4.tcp_comp_sack_delay_ns = 1000000
net.ipv4.tcp_comp_sack_nr = 44
net.ipv4.tcp_dsack = 1
net.ipv4.tcp_sack = 1
net.ipv4.tcp_timestamps = 1
net.netfilter.nf_conntrack_timestamp = 0

Hier deine Änderungsvorschläge:

[root@zat264 gl]# sysctl net.ipv4.tcp_timestamps=0
net.ipv4.tcp_timestamps = 0
[root@zat264 gl]# sysctl net.ipv4.tcp_sack=0
net.ipv4.tcp_sack = 0
[root@zat264 gl]# sysctl net.ipv4.tcp_dsack=0
net.ipv4.tcp_dsack = 0

Backup gestartet:

[root@zat264 gl]# sudo mount.cifs //servername/ZEA-1_Users/ichderuser/ /mnt/privat-fs/ -o noserverino,vers=1.0,uid=1000,gid=100,rw,user="ichderuser",password="geheim"
[gl@zat264 ~]$ rsync -rluvh --delete --numeric-ids --exclude=.Trash-1000 --exclude=lost+found /mnt/Doku/  /mnt/privat-fs/Doku/
sending incremental file list
DCS_kopie2/
DCS_kopie2/256-DOC-20190514-GLang-dcs_kopie_kabelplan.dxf
...
...
sent 187.91M bytes  received 31.89K bytes  631.72K bytes/sec
total size is 8.69G  speedup is 46.24

Trommelwirbel, -- Es läuft einwandfrei durch.
Damit ist erst mal alles gelöst.
In der Hoffnung, dass später mit dem neuen Server alles besser klappt.
Meinen herzlichsten Dank nochmal für deine ausführlichen Erklärungen und der vielen Arbeit die da hintersteckt.
Gruß aus DN
Greg

GerBra
29.05.2019 14:04:17
Greg schrieb:

Zu d):
Ist die Verbindung unterbrochen, so kann ich auch mit einem 2.Terminal nicht mehr auf den Mountpunkt reinsehen.
Abbruch mit strg+c  geht auch nicht.
...
Übrigens auch Thunar macht dann nichts mehr. Man kann nichtmal mehr ein weiteres Thunarfenster benutzen.
Erst ein Reboot macht alles wieder in Ordnung. Dabei gibts dann failed unmount /mnt/privat-fs.
Nach 20Sekunden timeout bootet er dann.

Also diesen Punkt d) halte ich für den entscheidenden (neben den anderen Infos aus deinem Post)...
Es sieht also nach einem reinen Lastproblem zwischen beiden Seiten aus (also CPU+IO+NETIO Last).
Da es immer passiert wenn eine größere Anzahl von kleinen Dateien im Spiel sind würde ich auf (Disk/Dateisystem)-IO-Probleme als Ursache tippen. Für diese Anzahl muß z.B. der empfangende Rechner (der "Server" in deinem Fall) einen immens hohen Aufwand an Rechenzeit und eben Disk-Zugriffe leisten (Daten empfangen,prüfen,Datei anlegen,Daten schreiben,Datei schließen,Dateisystem aktualisieren,...). Das kann sich dann hochschaukeln bis eben dahin daß die Netzverbindung nicht mehr bedient werden können, dein Mount wegbricht da das System nicht mal mehr sagen kann: Hoppla, ich lebe noch! == Timeout. Kann sogar sein, daß noch nicht mal mehr ein ping funktioniert.
Das es wohl eben nicht ursächlich ein Netzproblem ist, dafür spricht daß große Dateien ok übertragen werden, der Aufwand ist geringer. Ebenso zeigt daß IMHO das rsync nicht der Verursacher im Sinne von "Fehler" ist.

Verursacher: Können natürlich beide Seiten sein. Jetzt gehe ich mal davon aus, daß sowohl Du wie auch dein IT-Kollege an einigermaßen "vernünftigen" PCs sitzen, "vernünftige" Betriebssysteme verwendet ihr ja beide schon <g>
Der (Windows)Server: Das scheint ja kein dedizierter, "richtiger" Server zu sein (zumindest was ich an Infos aus dem Thread im Kopf habe). Eventuell eine virtualisierte Lösung mit ggf. virtualisierter Netzkarte und ebensolchem (HD)-Speicherplatz. Nur mal angenommen, der ganze Server wäre eine einzige "Datei", Image, auf einem Host/Wirt-System und würde aus diesem Image auch noch die Freigaben (die du mountest) bereitstellen: beim ständigen Aktualisieren dieses Images - durch massenhafte Kopieraktionen in hoher Anzahl - muß dieses Image in bestimmten Intervallen immens oft neu geschrieben/aktualisiert werden. Was die virtualisierte Lösung, aber auch das Wirt-System "an den Rande der Verzweiflung" bringen kann.
Insofern könnte die "Lösung" wirklich außerhalb deiner Möglichkeiten liegen, würde sich also ggf. erledigen durch eine neue Art/Konzept des "Servers".

Zur Verdeutlichung vielleicht nochmal ein Beispiel: Deine funktionierende Übertragung per smbclient/mput klappte deswegen, weil dieses Verfahren die "Dateien" ggf. auf "sequentielle Art" übertragen hat, also schön "eine nach der anderen", keep slow, "Schneckentempo", Alt-Herren-Art <g>.
Heutige Systeme können zu Recht erwarten, daß jegliche Datenpakete(IO, Input/Output) von jedem beteiligten Subsystem (Net, Disk, CPU) in einer vernünftigen Zeitspanne abgearbeitet werden - daß betrifft dann Timeout-Mechanismen bei Netzpaketen, bei verwendeten Caches und bei Rechenzeit und ebenso beim Lesen/Schreiben auf nicht volatile Speichermedien. Das eben nicht Daten in irgendwelchen Queues verhungern, erneut gesendet oder schlichtweg verworfen werden - bis hin das ein System sagt: Och, jetzt kann ich nicht mehr, ich mach mal Pause, egal was der Rest der Welt von mir will...

Deine Möglichkeiten:
a) nutze top/htop um die Last auf deinem Client zu beobachten. top ist dafür ggf. besser, da es bei den CPUs die Wait-Spalte mitanzeigt. Du kannst/wirst auch eine hohe Last/Load haben, aber ggf. nicht als Verursacher sondern als "Leidtragender".

b) Teste beim Netztransfer wirklich nochmal das Verhalten wenn du auf deinem Client per sysctl SACK und Timestamps für die IPv4-Pakete ausschaltest.

c) Mount-Parameter für cifs/SMB:
Cifs/SMB ist ja nun bekanntlich wirklich nicht das effizienteste Netzwerkprotokoll was jemals in die Welt "reingepresst" wurde. NFS und SMB z.B. sind IMHO so diametral unterschiedlich "bequem", wie durch eine Tür reinzukommen anstatt durch ein "Window"s <g>
man mount.cifs zeigt trotzdem einige Möglichkeiten ggf. daran zu drehen um die Problemursache durch eine Art "Verlangsamung" evtl. zu vermeiden.
Am vielversprechendsten erscheinen mir die Optionen (also bei mount bei -o):
a) cache=none
b) rsize und wsize, hier ggf. mal mit den alten Defaultwerten von 16k oder noch geringer arbeiten.
c) fsc (da bin ich mir am Unklarsten ob das Einschalten was bringt)
d) actimeo (ggf. mal raufsetzen auf 2 oder 3 s ?)
Das erscheinen mir die sinnvollsten Möglichkeiten direkt am Mount der entfernten Freigabe anzusetzen. Um ggf. den Timeout, Zusammenbruch eben auf protokoll-Ebene schon zu vermeiden. Ach so, a) bis d) immer schön eins nach dem anderen ausprobieren, einzel oder in jeweils nachfolgender Kombination, sonst merkt man nicht was eine evtl. Veränderung nun bewirkt hat.

Viel Spaß beim Ausprobieren, Testen. Kostet halt immer eine Menge an Zeit....

Greg
29.05.2019 11:44:00

Hallo GerBra,
ich danke dir nochmals für deine ausführlichen Infos!!

Zu a):
Ich kann ein Backup nochmal anstossen wo eigentlich nichts mehr übertragen werden muss. Dann läuft alles durch.
Es passiert nur beim Schreiben auf dem Server ab einer Datenmenge von ca. 35MB bestehend aus vielen einzelnen Dateien.
Wenn ich z.B. ein archlinux-2019.03.01-x86_64.iso ca 600MB dort hineinkopiere läuft auch alles durch.

Zu b):
Am Projektordner Projekt DCS_Kopie2 liegt es nicht. Ich kann auf dem selben Server ein anderes Verzeichnis mounten und dort ein beliebiges Projekt kopieren das genauso zum Hänger führt.
Es liegt also nicht an genau diesem Verzeichnis, an diesem Mountpunkt und auch am genauen Server Ziellaufwerk oder Verzeichnis.

Zu c):
Platz genug ist da. Es wird ca. 115GB freier Raum angezeigt.

Zu d):
Ist die Verbindung unterbrochen, so kann ich auch mit einem 2.Terminal nicht mehr auf den Mountpunkt reinsehen.

$ cd /mnt/privat-fs
hier kein Prompt mehr.

Abbruch mit strg+c  geht auch nicht.
Terminalfenster so geschlossen.

Übrigens auch Thunar macht dann nichts mehr. Man kann nichtmal mehr ein weiteres Thunarfenster benutzen.
Erst ein Reboot macht alles wieder in Ordnung. Dabei gibts dann failed unmount /mnt/privat-fs.
Nach 20Sekunden timeout bootet er dann.

Zu e):
Das Paket cpdup gebaut mit Änderung der PKGBUILD
Dann habe ich mal das Werkzeug benutzt. Was dabei rauskam:

cpdup -dI /mnt/Doku/  /mnt/privat-fs/Doku/
Scanning /mnt/Doku/ ...
Scanning /mnt/Doku//kicadlibbak ...
Scanning /mnt/Doku//kicadlibbak/Seitenlayout ...
Scanning /mnt/Doku//kicadlibbak/components ...
Scanning /mnt/Doku//kicadlibbak/arduino.pretty ...
Scanning /mnt/Doku//kicadlibbak/footprint.pretty ...
Scanning /mnt/Doku//kicadlibbak/models3d ...

Nach ca. 10 Sekunden hing der Server schon wieder.
Übrigens auch bei cp -au .. das Gleiche wie bei cpdup.

Zu deinen anderen Punkten kann ich gerade mich nicht befassen. Das hole ich dann nach.
Nochmals vielen Dank für deine Mühen.

Gruß aus DN
Greg

GerBra
28.05.2019 18:38:34

Sorry, ich komme auch erst jetzt dazu mich zu melden...

Greg schrieb:

Jetzt 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.

Greg
27.05.2019 18:30:03
tuxnix schrieb:

...Ausgabe von rsync auch mal loggen. rsync.....> rsync.log..

Hallo tuxnix,
ich danke dir!!
Mit der Option --log-file=FILE für rsync kann ich versuchen mehr raus zu bekommen.
Kann ich erst morgen machen. Bis jetzt habe ich nur das journal vom Anfangspost.

Bis morgen.
Gruß Greg

Nachtrag:
Hier sind die rsync Logdateien:
Zunächst wenn alles funktioniert ohne Serverabbruch:

$ rsync -rluvh --log-file=/home/gl/rsync.log --delete --numeric-ids --exclude=.Trash-1000 --exclude=lost+found /mnt/Doku/  /mnt/privat-fs/Doku/
2019/05/28 11:24:13 [7622] building file list
2019/05/28 11:25:21 [7622] >f.sT...... bestellungen/Bestellungen.gnumeric
2019/05/28 11:25:55 [7622] *deleting   kicadprj/bessy_analogregler2/shapes3D/testpunkt.wrl
2019/05/28 11:25:55 [7622] *deleting   kicadprj/bessy_analogregler2/shapes3D/spectrol67x.wrl
..
..
2019/05/28 11:25:55 [7622] >f+++++++++ kicadprj/bessy_analogregler2/bessyreglerP3.dxf
..
..
2019/05/28 11:27:00 [7622] sent 18.94M bytes  received 12.49K bytes  113.15K bytes/sec
2019/05/28 11:27:00 [7622] total size is 8.49G  speedup is 448.17

Jetzt die Logdatei mit Serverabbruch Es wurde einfach ein Projekt kopiert mit ca. 170MB (DCS_kopie2).

$ rsync -rluvh --log-file=/home/gl/rsync.log --delete --numeric-ids --exclude=.Trash-1000 --exclude=lost+found /mnt/Doku/  /mnt/privat-fs/Doku/
2019/05/28 11:30:21 [7676] building file list
2019/05/28 11:30:25 [7676] cd+++++++++ DCS_kopie2/
..
..
2019/05/28 11:30:38 [7676] >f+++++++++ DCS_kopie2/DSP_Per_Ana/H4/bessy_nachbau_2.JPG

Nach 3 min. Abbruch (strg+c).

2019/05/28 11:33:50 [7676] rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at rsync.c(642) [sender=3.1.3]
2019/05/28 11:33:50 [7676] rsync error: received SIGINT, SIGTERM, or SIGHUP (code 20) at io.c(504) [generator=3.1.3]
[gl@zat264 ~]$ rsync: [generator] write error: Broken pipe (32)

Gruß aus DN
Greg

tuxnix
27.05.2019 17:35:41

Habe eine hoffentlich nicht allzu unbedarfte Idee dazu:

Dazu würde ich die Ausgabe von rsync auch mal loggen.
rsync.....> rsync.log
Hatte schon mal Abbrüche wg. I/O Fehlern.
Nur so, weil es immer nach 35MB passiert.

Greg
27.05.2019 12:20:00

Jetzt kommt die Nachlieferung von Logdateien:
zu a Der Server ist gemountet, ohne Übertragung von Daten:

# sysctl -a |grep -e sack -e timestamp
net.ipv4.tcp_comp_sack_delay_ns = 1000000
net.ipv4.tcp_comp_sack_nr = 44
net.ipv4.tcp_dsack = 1
net.ipv4.tcp_sack = 1
net.ipv4.tcp_timestamps = 1
net.netfilter.nf_conntrack_timestamp = 0

# ethtool -S enp3s0
NIC statistics:
     tx_packets: 12369
     rx_packets: 19413
     tx_errors: 0
     rx_errors: 0
     rx_missed: 0
     align_errors: 0
     tx_single_collisions: 0
     tx_multi_collisions: 0
     unicast: 16694
     broadcast: 2585
     multicast: 134
     tx_aborted: 0
     tx_underrun: 0
# 

zu b: Während ein Backup angestossen wurde. Geringe Dateimengen Übertragung nicht unterbrochen:

# sysctl -a |grep -e sack -e timestamp
net.ipv4.tcp_comp_sack_delay_ns = 1000000
net.ipv4.tcp_comp_sack_nr = 44
net.ipv4.tcp_dsack = 1
net.ipv4.tcp_sack = 1
net.ipv4.tcp_timestamps = 1
net.netfilter.nf_conntrack_timestamp = 0

# ethtool -S enp3s0
NIC statistics:
     tx_packets: 3691
     rx_packets: 7459
     tx_errors: 0
     rx_errors: 0
     rx_missed: 0
     align_errors: 0
     tx_single_collisions: 0
     tx_multi_collisions: 0
     unicast: 6981
     broadcast: 454
     multicast: 24
     tx_aborted: 0
     tx_underrun: 0

zu c: Nachdem der Server unterbrochen ist 33MB von 65MB übertragen.

# sysctl -a |grep -e sack -e timestamp
net.ipv4.tcp_comp_sack_delay_ns = 1000000
net.ipv4.tcp_comp_sack_nr = 44
net.ipv4.tcp_dsack = 1
net.ipv4.tcp_sack = 1
net.ipv4.tcp_timestamps = 1
net.netfilter.nf_conntrack_timestamp = 0

# ethtool -S enp3s0
NIC statistics:
     tx_packets: 56602
     rx_packets: 210361
     tx_errors: 0
     rx_errors: 0
     rx_missed: 0
     align_errors: 0
     tx_single_collisions: 0
     tx_multi_collisions: 0
     unicast: 50929
     broadcast: 151753
     multicast: 7679
     tx_aborted: 0
     tx_underrun: 0
# 

Naja, meine Kenntnisse reichen jetzt nicht um da was zu sehen.
Bei der Übertragung von c habe ich mal 10min. gewartet ob da noch was kommt.
Nichts. bleibt so unterbrochen. Die Übertragung geht nicht weiter.

Nochmals Besten Dank an Euch!!
Gruß aus DN
Greg

Greg
25.05.2019 20:07:17
chepaz schrieb:

....Sorry, musste ich loswerden. Das ist ein täglicher Kampf zwischen IT und Anwender smile

Ich wollte jetzt nicht auf die IT-Leute rumhacken.
Ich selber habe nicht das nötige Wissen warum gerade das benutzt wird. Das da im Hintergrund viel rumwerkelt kann ich mir schon vorstellen. Rechteverwaltung rsynckram. Mit dem IT-Mann mit dem ich kontakt hatte, der war schon hilfsbereit und wenn er gekonnt hätte, dann wäre da auch mehr drin gewesen.
Wenn aber das Problem bei netapp liegt dann kann er wohl daran nichts machen.
Für die täglichen Backups mit relativ wenigen Daten reicht es noch. Nur wenn ich ganze Projekte mal eben sichern muss, dann klemmts. Dann werde ich wohl den smbclient benutzen. Das war auch ein Tip vom IT-Mann.
Ab August ist das dann hoffentlich Geschichte.

Bis denn..
Greg

Fußzeile des Forums

Powered by FluxBB