Hallo Leute, ich habe auf meinem Server ein größeres Problem mit dem Samba-Server. Ich habe nach dem Einrichten des Servers einen Großteil meiner PC-Daten auf den Server ausgelagert, da er eine größere Platte hat. Das ganze lief über Nacht, daher weiß ich nicht, wie lange es gedauert hat. Ich wollte jetzt eine Grafik mit ca. 15 MB öffnen. Nach ca. 1,5 Stunden hatte Photoshop es geschafft. Da gleiche Problem tritt auch beim kopieren von Dateien auf. Hat jemand eine Idee, an welcher Stelle ich da irgendwas falsch konfiguriert haben könnte. Oder soll ich vielleicht mal irgendwelche Konfigurationsdateien posten?? Gruß Christopher --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Hallo, Christopher Nehls wrote:
Ich habe nach dem Einrichten des Servers einen Großteil meiner PC-Daten auf den Server ausgelagert, da er eine größere Platte hat. Das ganze lief über Nacht, daher weiß ich nicht, wie lange es gedauert hat.
Aber es sind schon alle Daten angekommen? Moeglich ist ja, dass -wenn es sehr lange dauert- irgend ein Timeout zuschlaegt und der Kopiervorgang vorzeitig beendet wird...
Ich wollte jetzt eine Grafik mit ca. 15 MB öffnen. Nach ca. 1,5 Stunden hatte Photoshop es geschafft. Da gleiche Problem tritt auch beim kopieren von Dateien auf.
Das ist natuerlich weniger gut...
Hat jemand eine Idee, an welcher Stelle ich da irgendwas falsch konfiguriert haben könnte.
Schau dazu mal zunaechst die folgende Seite an: ftp://ftp.samba.org/pub/samba/docs/textdocs/Speed.txt ftp://ftp.samba.org/pub/samba/docs/textdocs/Speed2.txt Anschliessend noch einige Dinge: - Wie sieht es aus, wenn Du z.B. mittels "ftp" Daten zwischen Server und Client austauschst? Ist dort die Geschwindigkeit aehnlich niedrig, ist das kein Samba-spezifisches Problem, sondern in einer darunterliegenden "Schicht" zu suchen. Wenn ein "ftp"-Datenaustausch allerdings wesentlich schneller ist (so wie man es normalerweise erwartet), dann handelt es sich wohl eher um ein Problem auf SMB-Ebene. - Ich hatte mal ein aehnliches Problem, das dadurch verursacht wurde, indem eine Netzwerkkarte, die an einem normalen Hub hing, versehentlich im "Full-Duplex-Modus" lief. Das hatte natuerlich eine Menge Collisions zur Folge und die Geschwindigkeit ging auf ein Minimum zurueck. Ein Umkonfigurieren der Karte loeste das Problem. - Zumindest frueher war es notwendig, unter Samba zusaetzlich die Option: socket options = TCP_NODELAY zu setzen. Das macht aber zumindest "samba-2.0.7" von Haus aus, wenn man es nicht ausdruecklich anders haben moechte.
Oder soll ich vielleicht mal irgendwelche Konfigurationsdateien posten??
Wenn es denn wirklich an Samba liegt, hilft vielleicht zunaechst mal ein Update auf Samba-2.0.7 (wenn nicht sowieso schon vorhanden). Wenn das nicht hilft, waere evtl. die "global"-Sektion aus der "smb.conf" interessant - wenn es nicht zu lang ist (evtl. redundante Eintraege entfernen). Gruss, Steffen --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
- Wie sieht es aus, wenn Du z.B. mittels "ftp" Daten zwischen Server und Client austauschst? Ist dort die Geschwindigkeit aehnlich niedrig, ist das kein Samba-spezifisches Problem, sondern in einer darunterliegenden "Schicht" zu suchen. Wenn ein "ftp"-Datenaustausch allerdings wesentlich schneller ist (so wie man es normalerweise erwartet), dann handelt es sich wohl eher um ein Problem auf SMB-Ebene.
3 MB in 5 sek. ist wohl OK. Anbei die global-Einstellungen aus der smb.conf: [global] workgroup = NEHLS GRAFIK null passwords = yes netbios name = KENOBI socket options = TCP_NODELAY keepalive = 10 default service = Serverplatte1 map to guest = Bad User os level = 2 username map = /etc/user.map write raw = yes read raw = yes Und hier ein Musterverzeichnis: [online] comment = Online copy = Serverplatte1 path = /daten/online public = yes Schon mal ganz vielen Dank für die Hilfe!! --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Hallo, Christopher Nehls wrote:
3 MB in 5 sek. ist wohl OK.
Ja. Hast Du das auch in beide Richtungen probiert?
Anbei die global-Einstellungen aus der smb.conf:
[global] workgroup = NEHLS GRAFIK
Ich wuerde in die Workgroup keine Leerzeichen setzen... Sicher ist sicher.
null passwords = yes
Ok, wenn Du meinst. ;-)
netbios name = KENOBI
Auch klar.
socket options = TCP_NODELAY
Diese Option habe ich bei mir auch drin, wobei es IMHO bei den neueren Samba-Versionen nicht mehr noetig ist, da defaultmaessig vorhanden. Diese Option hat bei mir ca. 20 % Geschwindigkeitszuwachs gebracht.
keepalive = 10
Habe ich nicht drin. Ist im Normalfall IMHO nicht notwendig.
default service = Serverplatte1
Den Share "Serverplatte1" hast Du auch definiert?
map to guest = Bad User
Klar.
os level = 2
Betrifft das Browsing-Verhalten, das jetzt nicht das Problem sein sollte. Browsing ist ein anderes (durchaus umfangreiches) Kapitel... ;-)
username map = /etc/user.map
Auch das sollte mit Deinem Geschwindigkeitsproblem nicht unmittelbar zu tun haben.
write raw = yes read raw = yes
Hast Du "read raw" mal testweise abgeschaltet. Manche Clients haben damit Probleme...
Und hier ein Musterverzeichnis:
[online] comment = Online copy = Serverplatte1
Hier loest sich meine Frage, die ich oben bzgl. des Vorhandenseins des Shares "Serverplatte1" von selbst. ;-)
Schon mal ganz vielen Dank für die Hilfe!!
Bitte! Vielleicht kommen wir ja dem Problem noch auf die Spur. ;-) Stehen in den Samba-Logfiles (speziell "log.smb") irgendwelche Meldungen drin, die auf die Fehlerursache hindeuten koennten? Gruss, Steffen --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
workgroup = NEHLS GRAFIK
Ich wuerde in die Workgroup keine Leerzeichen setzen... Sicher ist sicher.
Mhh, da müßte ich einiges an Rechnern umstellen. Das macht aber denke ich keine Probleme
write raw = yes read raw = yes
Hast Du "read raw" mal testweise abgeschaltet. Manche Clients haben damit Probleme...
Habe ich gerade erst reingenommen, bringt aber keine Veränderung.
Stehen in den Samba-Logfiles (speziell "log.smb") irgendwelche Meldungen drin, die auf die Fehlerursache hindeuten koennten?
Weiß ich nicht, aber hier ein Ausschnitt: [2000/07/09 18:29:14, 1] smbd/service.c:make_connection(521) zentrale (192.168.4.250) connect to service Serverplatte2 as user root (uid=0, gid=0) (pid 28822) [2000/07/09 18:29:28, 0] smbd/oplock.c:oplock_break(905) oplock_break resend [2000/07/09 18:29:38, 0] smbd/oplock.c:oplock_break(905) oplock_break resend [2000/07/09 18:29:48, 0] smbd/oplock.c:oplock_break(905) oplock_break resend [2000/07/09 18:29:58, 0] smbd/oplock.c:oplock_break(922) oplock_break: receive_smb timed out after 30 seconds. oplock_break failed for file Scans zum brennen/Diane Boesch.tif (dev = 303, inode = 2932238). [2000/07/09 18:29:58, 0] smbd/oplock.c:oplock_break(992) oplock_break: client failure in break - shutting down this smbd. [2000/07/09 18:29:58, 1] smbd/service.c:close_cnum(557) zentrale (0.0.0.0) closed connection to service Serverplatte2 [2000/07/09 18:29:58, 1] smbd/service.c:close_cnum(557) zentrale (0.0.0.0) closed connection to service backoffice [2000/07/09 18:29:58, 1] smbd/service.c:make_connection(521) zentrale (192.168.4.250) connect to service Serverplatte2 as user root (uid=0, gid=0) (pid 28823) --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
Hallo, hast Du mal geprueft, ob bei Up- oder Download merklich verschiedene Geschwindigkeiten auftreten (sowohl bei FTP als auch bei Samba)? Christopher Nehls wrote:
Weiß ich nicht, aber hier ein Ausschnitt:
[2000/07/09 18:29:14, 1] smbd/service.c:make_connection(521) zentrale (192.168.4.250) connect to service Serverplatte2 as user root (uid=0, gid=0) (pid 28822) [2000/07/09 18:29:28, 0] smbd/oplock.c:oplock_break(905) oplock_break resend [2000/07/09 18:29:38, 0] smbd/oplock.c:oplock_break(905) oplock_break resend [2000/07/09 18:29:48, 0] smbd/oplock.c:oplock_break(905) oplock_break resend [2000/07/09 18:29:58, 0] smbd/oplock.c:oplock_break(922) oplock_break: receive_smb timed out after 30 seconds. oplock_break failed for file Scans zum brennen/Diane Boesch.tif (dev = 303, inode = 2932238). [2000/07/09 18:29:58, 0] smbd/oplock.c:oplock_break(992) oplock_break: client failure in break - shutting down this smbd.
Dass "oplock_breaks" auftreten ist ja durchaus normal. Diese Sache mit dem "shutting down" finde ich aber nicht so toll. Andererseits finde ich solche Dinge auch in meinen Logfiles, ohne dass die User ueber solche Probleme hinsichtlich der Geschwindig klagen. Schalte doch mal die Oplocks testweise ab und schaue, ob sich dann die Situation bessert. Gruss, Steffen --------------------------------------------------------------------- To unsubscribe, e-mail: suse-linux-unsubscribe@suse.com For additional commands, e-mail: suse-linux-help@suse.com
participants (2)
-
moser＠egu.schule.ulm.de -
service＠nk-net.de