Jedoch finde ich eine MTU von 9000 auch sehr abenteuerlich. Ich werde mal die Tage testen, unter welchen Umständen OSX diesen Werte vorgibt.

Obwohl wie beschrieben alle Mac-Clients diesen Fehler zeigten und weil ich nach den Meldungen, daß es hier und da mit SL auch fehlerfrei funktioniert, nicht davon ausgehen wollten, daß die Mädels & Jungs in der Apfel-Entwicklungsabteilung etwas so tolles wie SL gleich in elementarsten Funktionen an den Grund reißen, ging ein umfangreicheres Netzwerk-Testen los.

- Ich tauschte Kabel wo der Tester auch nur einen Moment beim Einstecken auf einem Pin minimal flackerte.
- Ich ging auch nochmal alle Dosen/Unterputzleitungen durch. Alles bestens.
- Zuletzt ging es an die Switches.

Und siehe da: Auf einem jede Menge RuntsRX. Der Switch, auf den die Grafiker geschaltet waren, empfing also “Paketsplitter” bzw. Pakete kleiner 64Bytes, dem Minimum. Ich tauschte aus Paranoia zunächst den Switch. Selbe Statistik. Die Kontrolle der Ausgabe von ifconfig auf den Macs mit SL ergab: Allesamt hatten die Ethernet-Schnittstelle automatisch konfiguriert – 1000MBit, FullDuplex mit FlowControl und JumboFrames (also MTU 9000).
Eine Apfelkiste, die ich testweise platt gemacht hatte, um mit Leopard gegenzutesten funktionierte übrigens hervorragend am Fileserver. Fast volle Auslastung der Netz-Bandbreite. Gleiche Einstellungen (mit 9000er MTU). Das vorübergehende Deaktivieren der JumboFrames auf einem der SL-Rechner bzw. besser gesagt die manuelle Konfiguration auf 1000MBit, FullDuplex mit FlowControl und MTU 1500 ließ den betreffenden Rechner sofort wieder aus seinem “Finder klemmt im Ballonmodus”-Schlaf aufwachen. Keine Störungen. Mounten, unmounten, Standby, wieder mounten, nochmal Standby – alles bene.

Fazit: Grand Central Dispatch ist womöglich so großartig und so zentral, daß der Netstack nach kurzem Powernapping im Standby schlicht die Daten hexelt, ehe sie ins Kabel wandern. Ist es das, was Apples Marketingabteilung als Kernel-”Multithreading” beschrieb? tcpdump sieht davon offenbar (noch) nichts. Vermutlich weil es dank GCD mit dieser Hexelei etwas anfangen kann.

Ich würde die [b]volle[/b] Rechnung am liebsten Apple schicken. Vielen Dank nochmal für das Feedback!

Vielen Dank für das Script. Wird gleich verbaut

Was die unix extensions angeht: Ist hatte bei der Konfiguration ein hartnäckiges Rechteproblem. Ich weiß nicht mehr, ob unix extensions = no Teil der Lösung oder ein Überbleibsel ist.
Ungefähr so muß es sich zugetragen haben: http://bugs.contribs.org/show_bug.cgi?id=4164

##########################
#!/bin/sh
# Meta-Muell vom RAID loeschen v0.1

# Zu saeubernde Verzeichnisse
DIRECTORIES=

for DIR in $DIRECTORIES
do
find ${DIR} -name .DS_Store | xargs rm -f ;
find ${DIR} -name Thumbs.db | xargs rm -f ;
done
##########################

Warum wurden die unix extensions deaktiviert?

[global]
workgroup = WORKGROUP
netbios name = Firma Server
server string = Gentoo Samba %v

security = USER
encrypt passwords = true
hosts deny = 0.0.0.0/0
hosts allow = 127.0.0.1 xxx.20.126.140
unix extensions = no

#veto files = /.AppleDB/.AppleDouble/.AppleDesktop/.DS_Store/:2eDS_Store/Network Trash Folder/Temporary Items/TheVolumeSettingsFolder/.@__thumb/.@__desc/
delete veto files = yes

load printers = no
show add printer wizard = no
printing = none
printcap name = /dev/null
disable spoolss = yes

###

(Es ist kein Drucker vorhanden und mit den letzten Zeilen spare ich mir CUPS-Fehlermeldungen in den Logs)

Im privaten Bereich betreibe ich exakt die gleiche Konfiguration und habe auch mit Standby-Problemen zu kämpfen. Allerdings unter umgekehrten Vorzeichen: Nach einigen Tagen Standby kann man auf die Shares nicht mehr zugreifen und sie auch nicht auswerfen. Dann hilft nur ein Neustart.

Das Skript zum Entfernen der “Dot”-Dateien würde mich interessieren

Immerhin hat das Update auf SL 10.6.2 bewirkt, daß die über bonjour/avahi publizierten File-Services nach dem WakeUp aus dem Mac-Client-Standby sichtbar bleiben. tcpdump/wireshark zeigt keine verdächtigen Meldungen. Die shares auf dem Server werden wöchentlich via cron-job von “dot”-Files bereinigt, deren Erstellung aber prinzipiell erlaubt ist.

### smb.conf : [global] ###

[ global ]
interfaces = eth0
unix charset = UTF8
workgroup = $workgroup
netbios name = $servername
server string = $aboutserver
hosts allow = $somehosts
hosts deny = $somehosts
security = USER
encrypt passwords = yes
socket options = TCP_NODELAY SO_RCVBUF=65536 SO_SNDBUF=65536
max xmit = 65535
large readwrite = no
create mask = 0777
directory mask = 0777
force create mode = 0777
force directory mode = 0777

###

Das Drucken auf über eben diesen Server eingebundenen Druckern funktioniert unter allen Umständen hervorragend. Das Problem zeigt sich im übrigen bei allen Macs der Firma hier. Die Rechner sind teils aus der Schachtel. Einzige Maßnahme: Leopard im Auslieferungszustand aktualisiert, anschließend Update auf Snow Leopard. Eine zerschossene Lokal-Konfiguration infolge intensiver Bastelwut ist (leider) auszuschließen.

Aber schonmal schön zu hören, daß es kein generelles Problem ist.

[1] Man binde mindestens eine SMB-Resource ein.

[2] Man versetze den Rechner in den Standby-Modus.

[3] Man reaktiviere den Rechner(, dessen netmounts danach auch noch alle verfügbar sind).

[4] Man unmounte die SMB-Resource.

Danach läßt sich vom demselben Server via Finder keine Resorce mehr mounten.