paulbaumann
Anmeldungsdatum: 14. September 2018
Beiträge: Zähle...
|
Vorgang Update von Ubuntu 18.04 auf 20.04 hat negative Folgen
Um ein Share auf der Sat-Box anzuzeigen dauert jetzt geschlagene 50 Sekunden und beim nächsten anzeigen (auch sofort danach) dann wieder...
Vorher unter Ubuntu 18.04 / SMB1 je 5 Sekunden...
Die Samba-Konfig habe ich beim Update so übernommen wie Sie war!
Unter Windows sind die sofort da und rasend schnell, nun mit 2.5GB dank der Treiber-Unterstützung Realtek 8156B von Ubuntu 20.04.
Ich überlege schon mal SMB1 auf dem Server zu erlauben aber soll man ja nicht weil böse unsicher..
Glaube aber nicht das das die Ursache ist... Vielleicht hat ja noch Jemand einen Tip bzgl. des SMB, irgendwelche socket options haben nichts gebracht in der Konfig,
ist ja unter Windows auch die volle 2.5GB Geschwindigkeit beim schreiben da.
Auf name resolve order reagiert er allergisch in der Konfig, egal was ich da reinschreibe (gibt ja nur die 4 Sachen bcast lmhosts host wins) hat zur Folge das weder die Windows Clients noch die Unix-Boxen irgendein Share erkennen.
Ging auch unter Ubuntu 18.04. Vielleicht durch die neue Samba-Version. Na vielleicht hat ja noch Jemand eine Idee.
|
chr123
Anmeldungsdatum: 19. Juli 2018
Beiträge: 1610
|
Willst du jetzt einen Share einhängen oder eine Freigabe erstellen?
|
dingsbums
Anmeldungsdatum: 13. November 2010
Beiträge: 3337
|
Wie greifst du auf das Share zu (Hostname / FQDN / IP-Adresse)? Teste bitte alle 3 Varianten, gibt es einen Unterschied?
|
paulbaumann
(Themenstarter)
Anmeldungsdatum: 14. September 2018
Beiträge: 24
|
chr123 → nein ich habe ja nichts geändert, die Freigaben waren serverseitig natürlich erstellt in der smb.conf und die wurde von mir beim Update beibehalten wie Sie war.
Und der Zugriff von Windows Clients funktioniert natürlich problemlos, nur die Enigma2 Sat-Boxen unterschiedlicher Bauart und unterschiedlicher Software nehmen das krumm
was auch nicht vollständig stimmt, weil nach 50 Sekunden Wartezeit geht es ja... dingsbums → werde ich testen heute oder morgen Abend, ich greife clientmäßig zu über die Mount-Verwaltung via CIFS und habe da nur vers=2.0 oder 3.0 ergänzt und schon kann man die Mounts wieder einbinden (offensichtlich wurde vor dem Update stets SMB1 benutzt)
Zugriff erfolgt über Hostname, das war immer so aber das ist kein Aufwand mal probeweise die IP-Adresse reinzuhämmern, ich werde berichten
|
paulbaumann
(Themenstarter)
Anmeldungsdatum: 14. September 2018
Beiträge: 24
|
So nun zu den Tests.
Das mit den unterschiedlichen Zugriffen geht so nicht und ist nicht nötig.
Die Enigma Freigabenverwaltung nimmt immer die IP Adresse. Der Servername kann eingetragen werden und wird auch aufgelöst.
Steht auch lokal und im Server in der hosts...
Im Netzwerkbrowser bei Enigma zeigt er alle Shares die online sind und offline (sein sollen) korrekt, das dauert alles ca. eine Sekunde.
Unter Freigabeoptionen habe ich nur rw stehen gehabt, nach Update Ubunt 18.04 zu 20.04 waren die Freigaben weg.
Erklärung war klar, es wird im neuen Samba kein SMB1 mehr standardmäßig erlaubt.
Bei Änderung der Freigabeoptionen zu rw,vers=2.0 oder rw,vers=3.0 waren Sie wieder da.
Die Ergebnisse, diesmal mit Stopuhr:
Unter rw,vers=3.0 dauert es 51 Sekunden
Unter rw,vers=2.0 dauert es 48 Sekunden
Unter Erzwingung der Version 1.0 mit
client min protocol=NT1
server min protocol=NT1
dauert es 28 Sekunden, auch trotzdem viel zu lange gegenüber Ubuntu 18.04 mit SMB1 mit vermuteten 4 Sekunden.
Mein weiteres NAS (Qnap, Consumer) braucht ebenso knapp 4 Sekunden.
Im Sat-Forum gefunden das man in der Sat-Box die smb.conf abändern soll
aus
security = user
mache
security = share
Ergebnis:
Unter rw,vers=3.0 dauert es 45 Sekunden, schneller aber nicht signifikant.
Mein Qnap reagiert darauf nun in unter 2 Sekunden...
Auf dem Server kann ich nicht security = share einstellen, dann sind die Shares schlicht weg...
Eine weitere Vermutung wäre die Netzwerkanbindung, da ich ja mein Ubuntu auf 20.04 deshalb angebunden habe weil ich nun (funktionierendes!) 2.5 GB Netzwerk habe.
Deshalb gebe ich mal die fstab anonymisiert weiter, vielleicht fällt da Jemand was auf was zu ändern wäre: cifs password=xxx,x-systemd.automount,vers=3.0,rsize=8192,noauto,wsize=8192,x-systemd.idle-timeout=60,rw,x-systemd.device-timeout=15,x-systemd.mount-timeout=15,username=xxx,soft,nofail 0 0 Da sind so ein paar timeout-Einstellungen mit denen ich nichts anfangen kann oder vielleicht verschluckt er sich an der 8192 bei der Netzwerkeinstellung.
Die Sat-Boxen haben GBit-Ethernet, die Werte oben habe ich der Dreambox DM920 entnommen.
Alllerdings vermute ich in der Tat irgendwelche Zugriffsrechte, weiß bloß nicht wo noch ansetzen...
|
paulbaumann
(Themenstarter)
Anmeldungsdatum: 14. September 2018
Beiträge: 24
|
Noch eine Ergänzung:
Die Zeiten im Post direkt obendrüber beziehen sich auf das öffnen des Verzeichnisses im Enigma2 Mediaportal.
...vielleicht sollte ich das mal im Enigma2 Forum beschreiben, oder hat noch Jemand einen Tip??
|
paulbaumann
(Themenstarter)
Anmeldungsdatum: 14. September 2018
Beiträge: 24
|
Habe in meiner Not nun die NFS Kernel Tools installiert und die Share per NFS eingehängt.
Da belieben noch 16 Sekunden übrig die ich warten darf.
Mit NFS hatte ich mal vor 6...7 Jahren rumgespielt, da waren es 2 Sekunden...
Zumindest scheint der Verzeichniswechsel kürzer zu sein wenn ich die Share mit NFS einbinde, bei SMB dauert das ja auch dann jeweils geschlagene 50 Sekunden.
Bei NFS ca. 3 bis 4 Sekunden.
Was zum Geier ist bei Ubuntu 20.04 so anders als bei allen anderen Versionen seit Ubuntu Alpha 9 ???
Ich stelle das jetzt parallel in das enigma2 - Forum, vielleicht haben die ja eine schnellere Antwort...
|
paulbaumann
(Themenstarter)
Anmeldungsdatum: 14. September 2018
Beiträge: 24
|
übrigens 2 Posts weiter oben ist mir ein Schreibfehler unterlaufen.
Streiche Mediaportal, setzte EMC (Enhanced Movie Center)
Vielleicht hat deshalb Keiner geantwortet, denn im MediaPortal kann man natürlich keine Freigaben einbinden, sorry für den Fehler.
|
Newubunti
Anmeldungsdatum: 16. Februar 2008
Beiträge: 4768
|
Hallo, ich habe keine eigene Erfahrung damit, aber laut dem folgenden Thread, https://unix.stackexchange.com/questions/390093/very-slow-cifs-smb-performace soll bei cifs-Performance-Problemen die Option cache=loose helfen können. Dabei aber auch auf den nachteiligen Effekt dieser Option achten. Im Heimnetz aber wahrscheinlich häufig zu vernachlässigen. Davon abgesehen sollte man mit Performnace-Tuning bei Samba eher zurückhaltend sein, siehe: https://wiki.samba.org/index.php/Performance_Tuning Die Im Netz kursierenden Tipps diesbezüglich sind in aller Regel veraltet. Außerdem wäre bei einer Anfrage zu Samba die Angabe der smb.conf schon hilfreich. Wenn die so alt ist, wie sich das im vorletzten Post andeutet, sind da im Zweifel auch Optionen drin, die man unter Umständen heute nicht (mehr) braucht und dann unter Umständen eher hinderlich als förderlich sind. LG,
Newubunti
|
paulbaumann
(Themenstarter)
Anmeldungsdatum: 14. September 2018
Beiträge: 24
|
Ich werde das morgen mit cache=loose testen und dann hier berichten.
Bin aber skeptisch, denn ich glaube nicht das es ein Samba-Problem ist. Habe ja auch mit NFS Probleme.
Und alles lief bis einschließlich Ubuntu 18.04 ohne Probleme.
|
dingsbums
Anmeldungsdatum: 13. November 2010
Beiträge: 3337
|
Update von Ubuntu 18.04 auf 20.04 hat negative Folgen
Wie verhält sich eigentlich ein Live-System 20.04 (besser: 22.04)? Vielleicht resultiert dein Problem ja aus irgendwelchen Altlasten.
|
Newubunti
Anmeldungsdatum: 16. Februar 2008
Beiträge: 4768
|
dingsbums schrieb: Wie verhält sich eigentlich ein Live-System 20.04 (besser: 22.04)?
+1! Ich würde das auch mal mit einer sauberen Neuinstallation bzw. einem Live-System testen - wenn möglich. Oder aber Du durchforstest mal die Hardware-Kette von den Sat-Clients hin zum Server: Läuft der Switch auf Gigabit? Kabel mal tauschen/prüfen Arbeitsspeicher an Server und Clients (Menge/fehlerfrei)? etc.
Ich hatte mal Performance-Probleme "bei einem Debian 8 Server" (das war glaube ich Samba 4.9...). Allerdings war das Problem damals, dass das Kopieren von Dateien von Windows-Clients langsamer als erwartet war. Lösung war da eine Erweiterung des Arbeitsspeichers an den Clients von 4 GB auf 8 GB - waren damals noch Windows 7 Clients. Und ein mal hatte ich auch Performance-Zuwachs nach Austausch eines Switchs. Auch wenn SMB an sich nicht sehr performant ist, siehe auch, https://accedian.com/blog/troubleshooting-smb-performance/ liegt es häufig eher an der Hardware (im weiteren Sinne). Wenn Du den Server nun schon über Ubuntu-Generationen im Betrieb hast, dann kann eben auch immer mal der Punkt kommen, wo die neue Distribution mehr von der Hardware abverlangt, als die Hardware herzugeben im Stande ist. Ansonsten könntest Du auch mal ein Netzwerk-Dump von den Windows-Zugriffen im Vergleich zu den Sat-Box-Zugriffen machen, siehe auch: https://wiki.samba.org/index.php/LinuxCIFS_troubleshooting Allerdings würde ich davor eher mal eine testweise saubere Neuinstallation machen und die Hardware checken. Kommt aber auch immer auf das individuelle Setup an, was da im Zweifel erst mal einfacher zu prüfen ist. LG,
Newubunti
|
paulbaumann
(Themenstarter)
Anmeldungsdatum: 14. September 2018
Beiträge: 24
|
cache=loose in der cifs Freigabe am Client bringt genau nichts.
Wundert mich nicht da ich ja auch alternativ mit NFS das Problem am Client habe. (Client = DM920)
Nichts desto trotz ist ein Telnet- oder SSSH-login am Client mit dortigen Verzeichnisanzeigen
der Freigabe bzw. in den Verzeichnissen wechseln mittels im Telnet/SSH gestarteten mc (midnight commander)
völlig verzögerungsfrei möglich, quasi live.
Frage war Läuft der Switch auf Gigabit?
Ja habe von 18.04 auf 20.04 Ubuntu upgrade gemacht weil das nun eben nicht mehr der Fall ist, mein NAS (und Windows APC) hängen am
2.5 GByte Switch und zeigen auch volle 2.5 GByte Geschwindigkeit (getestet per Dateicopy große Dateien über eben jenes Share)
Ein Ubuntu 22.04 live system aufsetzen dauert, dann muss ich wohl mit nano die smb.conf anpassen um eine share reinzunehmen...
werde das auch versuchen... ...und berichten
|
chr123
Anmeldungsdatum: 19. Juli 2018
Beiträge: 1610
|
Der Ubuntu 20.04 soll doch nur als Client auf den Server (Enigma) zugreifen, oder? Warum dann überhaupt Samba installieren und Einstellungen an der smb.conf vornehmen? In deinem Fall dürfte ein mount via cifs in der fstab doch das sinnvollste sein. Also - damit wir mal ein paar Informationen zum Arbeiten haben - kannst du mal bitte folgende Ausgaben im Codeblock zeigen:
testparm -vs
cat /etc/samba/smb.conf
cat /etc/fstab
|
Newubunti
Anmeldungsdatum: 16. Februar 2008
Beiträge: 4768
|
paulbaumann schrieb: Deshalb gebe ich mal die fstab anonymisiert weiter, vielleicht fällt da Jemand was auf was zu ändern wäre: cifs password=xxx,x-systemd.automount,vers=3.0,rsize=8192,noauto,wsize=8192,x-systemd.idle-timeout=60,rw,x-systemd.device-timeout=15,x-systemd.mount-timeout=15,username=xxx,soft,nofail 0 0
Ich würde die ganzen Timeout-, rsize- und wsize-Angaben mal testweise rauswerfen - falls noch nicht geschehen (natürlich nicht ohne Backup des Ist-Zustandes). Eigentlich sollten die nicht notwendig sein und beruhen ja - wenn ich Dir richtig folgen kann - eventuell noch auf dem <=18.04-Stand und damit dem Status noch vor 2.5 Gigabit. Siehe auch: https://wiki.samba.org/index.php/Mounting_samba_shares_from_a_unix_client#Common_mount.cifs_options Hast Du an den Sat-Clients bezüglich des Netzwerks noch weitere solche Parameter konfiguriert? AFAIK lässt man heute beim Netzwerk erst mal alles auf Automatik - was Performance etc. anbelangt. AFAIK kommen die Kernel moderne OS damit besser klar bzw. sind darauf optimiert/eingestellt. Wenn man da manuell eingreifen will, dann muss man das in aller Regel in der gesamten Netzwerk-Hardwarekette aufeinander abgestimmt konfigurieren andernfalls kommt es eher zu Performance-Einbrüchen statt -Zuwächsen. LG,
Newubunti
|