Debian 8: samba/cifs extrem langsam (lstat)

[Boesmann]

Ich habe dieses Problem schon im Debianforum gepostet, leider hat da bisher keiner eine Idee...

Nach Upgrade auf Debian 8 habe ich ein ernstes Problem mit einem über cifs gemounteten Windows Share. Up- und Download sind gewohnt schnell, das Anzeigen großer Verzeichnisse mit ls ist dagegen furchtbar lahm geworden. Ebenso ein Abgleich von Verzeichnissen mit rsync (lstat call für jede Datei): mit Debian 7 braucht die Aktion 23 Sekunden, mit Debian 8 über 30 Minuten (die selbe Hardware).

Was ich erfolglos probiert habe:
- diverse "Tuning"-Einstellungen
- Downgrade auf samba und rsync aus Debian 7

Jetzt weiß ich nicht mehr weiter...woran kann es denn sonst noch liegen? Sollte ich vielleicht ein Kernel-Downgrade versuchen?
Ich freue mich über jede Idee!

 

[mathmos]

Was ich erfolglos probiert habe:
- diverse "Tuning"-Einstellungen

Jetzt weiß ich nicht mehr weiter...woran kann es denn sonst noch liegen? ...
Ich freue mich über jede Idee!

Hier wäre es sinnvoll wenn du verraten würdest, was welche Tuning-Einstellungen du gemacht hast. Die Wahrscheinlichkeit, dass dir sonst zu genau diesen geraten wird, halte ich nicht für gerade gering.

Weiterhin wären es auch interessant, mit welchen Optionen du mountest und wie deine smb.conf aussieht.

 

[Boesmann]

fstab Eintrag: [src=text]//srv.muster.de/01\040Mustermann /DEST cifs users,noauto,credentials=geheim,file_mode=0644 0 0[/src]
Ausgabe von mount (Debian 7): [src=bash]$ mount
//srv.muster.de/01 Mustermann on /DEST type cifs (rw,nosuid,nodev,relatime,sec=ntlm,unc=\\srv.muster.de\01)[/src]
Ausgabe von mount (Debian 8): [src=bash]$ mount
//srv.muster.de/01 Mustermann on /DEST type cifs rw,nosuid,nodev,relatime,vers=1.0,cache=strict,username=mustermann,domain=MUSTER,uid=1000,forceuid,gid=1000,forcegid,addr=123.45.6.789,file_mode=0644,dir_mode=0755,nounix,serverino,rsize=61440,wsize=65536,actimeo=1)[/src]
Der fstab Eintrag und sonstige Einstellungen sind auf allen Systemen identisch, ebenso die unveränderte standard smb.conf.

"Tuning"-Einstellungen:
- rsize, wsize, cache=loose

Da es vorher ja mit den selben Parametern gut lief (und auch jetzt auf 2 wheezy-Systemen immer noch gut läuft) glaube ich nicht mehr, dass es daran liegt.

EDIT:
Noch eine Info zum Server: [src=bash]$ smbclient -L
Domain=[MUSTER] OS=[Windows Server 2012 R2 Standard 9600] Server=[Windows Server 2012 R2 Standard 6.3]

Sharename Type Comment
--------- ---- -------
01 Disk
02 Disk
03 Disk
04 Disk
05 Disk
06 Disk
G$ Disk Clusterstandardfreigabe
IPC$ IPC Remote-IPC
Connection to srv.muster.de failed (Error NT_STATUS_RESOURCE_NAME_NOT_FOUND)
NetBIOS over TCP disabled -- no workgroup available[/src]
Auf den Server und seine Einstellungen habe ich keinen Einfluß.

 

[vtepes]

Was steht in den Logs?
Älteren Kernel versucht?

Ausserdem ist Jessie doch noch gar nicht released, warum macht man da n Update auf Produkltivsystemen?

 

[Boesmann]

Was steht in den Logs?

log.smbd: [src=bash][2014/12/17 08:48:08, 0] ../source3/smbd/server.c:1189(main)
smbd version 4.1.13-Debian started.
Copyright Andrew Tridgell and the Samba Team 1992-2013
[2014/12/17 08:48:08.268032, 0] ../lib/util/become_daemon.c:136(daemon_ready)
STATUS=daemon 'smbd' finished starting up and ready to serve connectionsFailed to delete pidfile /var/run/samba/smbd.pid. Error was Datei oder Verzeichnis nicht gefunden[/src]
log.nmbd: [src=bash][2014/12/17 08:48:07, 0] ../source3/nmbd/nmbd.c:907(main)
nmbd version 4.1.13-Debian started.
Copyright Andrew Tridgell and the Samba Team 1992-2013
[2014/12/17 08:48:07.952390, 0] ../lib/util/become_daemon.c:147(daemon_status)
STATUS=daemon 'nmbd' : No local IPv4 non-loopback interfaces available, waiting for interface ...NOTE: NetBIOS name resolution is not supported for Internet Protocol Version 6 (IPv6).
[2014/12/17 08:48:27.955792, 0] ../lib/util/become_daemon.c:136(daemon_ready)
STATUS=daemon 'nmbd' finished starting up and ready to serve connections*****

Samba name server NAME is now a local master browser for workgroup WORKGROUP on subnet 123.456.789.10[/src]
dmesg: Nichts ungewöhnliches.
Hab ich welche vergessen?

Älteren Kernel versucht?

Wie im Startpost schon geschrieben: Nein.

Ausserdem ist Jessie doch noch gar nicht released, warum macht man da n Update auf Produkltivsystemen?

Jessie ist schon im Freeze, da wird es nur noch stetig besser

 

[vtepes]

Ausser "vers=3.0" als Mount-Option und älteren Kernal ausprobieren fällt mir erstmal nichts ein

 

[gelöschter Benutzer]

@vtepes: gibt es schon vers=3.0? Ich dachte, das wäre die SMB-Version, also 2.0 das aktuellste?

Würde auch SMBv2 verwenden und dahingehend auch sec=ntlmv2 oder sec=krb5, letzteres ist bei erfolgreicher Config weitaus schneller.

Wheezy nutzt übrigens Samba 3.6 statt 4.1, da würde ich mir mal die Default-Einstellungen anschauen.

Was ist das für ein Server? Mal eine Kernelversion >3.10 versucht? Welche Version hast du denn jetzt? Smb.conf und testparm (evtl. Paket Samba installieren) auf den Systemen vergleichen!

 

[Boesmann]

Der Kernel ist 3.16, der Server ist (wie oben bereits geschrieben) ein Windows Server 2012 R2.
ver=1.0, ver=2.0, ver=2.1, ver=3.0 verhalten sich alle gleich. sec=ntlm oder sec=ntlmssp macht auch keinen Unterschied, sec=krb5 hat keine Wirkung (bleibt bei ntlmssp).

Samba 3.6 hatte ich bereits installiert, keine Verbesserung.

Und, wie gesagt, normales kopieren von Daten geht schnell, nur directory listings sind problematisch.

 

[Boesmann]

So, kleines Update:
Downgrade auf Kernel 3.2 -> Problem gelöst!

Problem gelöst? Leider nicht so ganz...einiges anderes funktioniert jetzt natürlich nicht mehr so optimal (z.B. nouveau).

Deshalb jetzt die nächste Frage:
Wie kann ich rausfinden woran genau das liegt und wie behebe ich das bei einem neueren Kernel? Ich habe kein Problem damit mir einen selber zu backen, aber da müsste ich natürlich erstmal wissen wo das Problem liegt...

 

[gelöschter Benutzer]

Du könntest die Kernel-Changelogs zwischen 3.2 und 3.16 nach Samba/CIFS durchsuchen und dir die commit-Messages anschauen.

Eventuell ist es ein unentdeckter Kernel-Bug, da freuen sich die Maintainer natürlich über eine Meldung.

 

[vtepes]

Ich würde jetzt bevor du grosse Frickelei anfängst im ersten Schritt den neusten LTS kernel versuchen (3.14), den wirds ja wohl in den Debian Repos geben?

 

[Boesmann]

Nö, gibt's nicht. Bei debian-snapshots gibt es 3.9, dazwischen leider nix.

 

[vtepes]

<insert generic rant zu Debian here >

Dann, naja - LTS-kernel von kernel.org mit exportierten Config selber bauen? Da gabs meine ich mal nen Weg gleich ne .deb zu erzeugen, damits nicht vorbei am Paketmanager ist. Ich hab Debian seit 2008 oder so nicht benutzt, gibt sicher Doku.
In jedem Fall kernel-updates entsprechend beim Paketmanager blacklisten.

Auf die Suche nach dem genauen Fehler würde ich mich nicht begeben, es sei denn du hast Zeit und Lust.

 

[gelöschter Benutzer]

Dann, naja - LTS-kernel von kernel.org mit exportierten Config selber bauen? Da gabs meine ich mal nen Weg gleich ne .deb zu erzeugen, damits nicht vorbei am Paketmanager ist. Ich hab Debian seit 2008 oder so nicht benutzt, gibt sicher Doku.

Nennt sich make-kpkg, Anleitung hier: https://www.debian.org/releases/etch/hppa/ch08s06.html.en

 

[Asseon]

das kann der Kernel build script auch selbstständig

mittels "make deb-pkg"

 

[gelöschter Benutzer]

Die make-Targets vom Kernel können aber eher in die Hose gehen als Debians eigenes Tool. Außerdem hat make-kpkg noch einige Optionen, die das make-Target iirc nicht hat.

 

[Boesmann]

Also ich hab doch noch diverse Kernelversionen in den Debian-Snapshots gefunden und durchprobiert. Der letzte funktionierende ist 3.11.2, der nächste, 3.12.6, zeigt das oben beschriebene Problem.

Die Änderungen zwischen diesen Versionen bezgl. cifs:
Debian Changelog: [src=bash]* cifs: Enable CIFS_SMB2[/src]
Kernel Changelogs: [src=bash] commit bf96a2e6b0f40b1e48992edde49e7eae8d5923d1
Author: Steve French <smfrench@gmail.com>
Date: Fri Nov 15 20:41:32 2013 -0600

setfacl removes part of ACL when setting POSIX ACLs to Samba

commit b1d93356427be6f050dc55c86eb019d173700af6 upstream.

setfacl over cifs mounts can remove the default ACL when setting the
(non-default part of) the ACL and vice versa (we were leaving at 0
rather than setting to -1 the count field for the unaffected
half of the ACL. For example notice the setfacl removed
the default ACL in this sequence:

steven@steven-GA-970A-DS3:~/cifs-2.6$ getfacl /mnt/test-dir ; setfacl
-m default:user:test:rwx,user:test:rwx /mnt/test-dir
getfacl: Removing leading '/' from absolute path names
user::rwx
group::r-x
other::r-x
default:user::rwx
default:user:test:rwx
default:group::r-x
defaultask::rwx
defaultther::r-x

steven@steven-GA-970A-DS3:~/cifs-2.6$ getfacl /mnt/test-dir
getfacl: Removing leading '/' from absolute path names
user::rwx
user:test:rwx
group::r-x
mask::rwx
other::r-x


commit 167f34b7d969836cf4faeb92edcb9cc20cfc72f2
Author: Pavel Shilovsky <piastry@etersoft.ru>
Date: Wed Oct 23 17:49:47 2013 +0400

CIFS: Fix symbolic links usage

commit eb85d94bdd91fb4dbea4ee465d4349cbea4eaaca upstream.

Now we treat any reparse point as a symbolic link and map it to a Unix
one that is not true in a common case due to many reparse point types
supported by SMB servers.

Distinguish reparse point types into two groups:
1) that can be accessed directly through a reparse point
(junctions, deduplicated files, NFS symlinks);
2) that need to be processed manually (Windows symbolic links, DFS);

and map only Windows symbolic links to Unix ones.[/src]
Ich sehe jetzt nicht wo da das Problem liegen könnte, vielleicht hat ja jemand mit mehr Ahnung eine Idee.

 

[gelöschter Benutzer]

Könnte ein Bug sein. Vielleicht funktionieren auch die UNIX Extensions bei dir nicht. Schau mal mit getfacl drüber, ob das alles gesetzt wird.

 

[Boesmann]

Vielleicht funktionieren auch die UNIX Extensions bei dir nicht.

Ja nun, es ist ein Windows-Server, von daher gibt es keine UNIX Extensions (siehe auch obige Ausgabe von mount, nounix bedeutet deaktivierte Extensions).