Lage:

Das folgende seltsame Problem ist auf einem einzelnen Dateiserver mit OmniOS r151018 (95eaa7e) aufgetreten, der Windows- und OS X-Gästen Dateien über SMB bereitstellt.

Das Speichern bestimmter Dateien (.docx, .xlsx, einige Bilder) über das Dialogfenster "Speichern unter ..." auf einer SMB-Freigabe führt zu einer Verzögerung von ca. 3 bis 5 Sekunden, wenn die Anwendung überhaupt nicht reagiert Datei wird normal gespeichert.

Das Problem trat "über Nacht" auf, ohne etwas mit dem Server zu tun, aber es ist schwierig, das genaue Datum zu bestimmen, da Beschwerden von Benutzern erst einige Zeit nach dem ersten Auftreten auftraten. Nach einem Neustart des Servers war ein vdev des gespiegelten Stammpools nicht verfügbar, bei näherer Betrachtung wurden jedoch keine Fehler auf dem Gerät festgestellt und es wurde erneut mit dem Pool verbunden. Das Problem besteht weiterhin.

Einige Beobachtungen:

• Dies geschieht auf allen Windows 7-Clients
• Dies geschieht für alle Dateigrößen
• Dies geschieht auf allen Freigaben dieses Computers, unabhängig von den Berechtigungen
• Dies geschieht für einen schnelleren Speicher, der über iSCSI von einem anderen Server auf den Host importiert wird
• Die normale Kopiergeschwindigkeit beträgt 110 MB / s über GBit Ethernet
• Daten und Root-Pool scheinen in Ordnung zu sein
• Dies geschieht nicht auf anderen Dateiservern
• Es passiert nicht, wenn die Datei lokal gespeichert und dann über den Explorer kopiert wird
• Es passiert nicht unter OS X (konnte es nur mit OpenOffice testen)
• dmesgzeigt mehrere Zählungen NOTICE: bge0: interrupt: flags 0x0 - not updated?mit unterschiedlichen Werten, aber dies war auch vorher der Fall und hat keinen Schaden angerichtet

Weitere Ideen / Pläne:

Da keine eindeutige Fehlermeldung gefunden werden kann, muss ich möglicherweise nach der Ursache suchen. Einige Dinge, die ich berücksichtigen werde ( Ergebnisse sind kursiv ):

• Ersetzen Sie die Broadcom-Netzwerkkarte durch eine Intel-Karte => hat keinen Unterschied gemacht
• Ersetzen Sie den Root-Pool durch SATA-SSDs (derzeit SLC-Speicher-USB-Sticks, die über 3 Jahre einwandfrei funktionierten ) => hat keinen Unterschied gemacht
• Überprüfen Sie das Netzwerk dazwischen (Hardware, durch direkte Verbindung zum Server)
• Verkehrserfassung mit WireShark: schwierig, wenn Sie nicht genau wissen, wonach Sie suchen
• Zurück zu einer früheren OmniOS-Boot-Umgebung / -Version, um Softwarekonflikte auszuschließen => hat keinen Unterschied gemacht
• Führen Sie Windows / Office-Updates zurück, um Fehler auszuschließen

• Entfernen Sie Dateien mit :(Doppelpunkt) in Dateinamen aus Snapshots. Der Vorschlag von txgsync für den von ewwhite => erstellten reddit-Thread machte keinen Unterschied

  Ich habe etwas Ähnliches gesehen, als die Windows-Funktion "Frühere Versionen" mit automatischen Schnappschüssen aktiviert wurde, die ein ":" - Zeichen enthalten. Nur damit in den Wind schießen, ist aber möglicherweise einen Blick wert, da das Zeichen ":" in Windows-Dateinamen nicht zulässig ist.

• Überwachung von Dateizugriff: wie shodanshok vorgeschlagen, ich verwenden DTraceund diese Skript - Dateizugriff zu überwachen. Ich habe es beim Speichern der bereits geöffneten Datei verwendet, nicht verwandte Ausgaben und persönliche Informationen entfernt und das Ergebnis konzentriert sich auf drei Dateien:

  CPU ID       FUNCTION:NAME
  1   18753    fop_open:entry Open: Workbook
  0   18181 fop_create:return Create: temp_1
  0   18753    fop_open:entry Open: temp_1
  0   18753    fop_open:entry Open: Workbook
  0   18753    fop_open:entry Open: Workbook
  0   18753    fop_open:entry Open: temp_1
  0   18888  fop_rename:entry Rename: Workbook -> temp_2
  0   18888  fop_rename:entry Rename: temp_1 -> Workbook
  0   18753    fop_open:entry Open: Workbook
  0   18753    fop_open:entry Open: temp_2
  0   18892  fop_remove:entry Remove: temp_2
  0   18753    fop_open:entry Open: Workbook
  0   18753    fop_open:entry Open: Workbook
  

  Das gleiche Verfahren auf einem anderen Server, auf dem das Problem nicht auftritt, führt zu einem ähnlichen Ergebnis:

  CPU ID       FUNCTION:NAME
  1   25182 fop_create:return Create: temp_1
  1   25750    fop_open:entry Open: temp_1
  1   25750    fop_open:entry Open: Workbook
  1   25750    fop_open:entry Open: temp_1
  1   25750    fop_open:entry Open: Workbook
  1   25750    fop_open:entry Open: temp_1
  1   25889  fop_rename:entry Rename: Workbook -> temp_2
  1   25889  fop_rename:entry Rename: temp_1 -> Workbook
  1   25750    fop_open:entry Open: Workbook
  1   25750    fop_open:entry Open: temp_2
  1   25893  fop_remove:entry Remove: temp_2
  1   25750    fop_open:entry Open: Workbook
  1   25750    fop_open:entry Open: Workbook
  1   25750    fop_open:entry Open: Workbook
  

  Ich habe walltimestampdem Skript auch timestamps ( ) hinzugefügt , aber in beiden Fällen finden alle Dateivorgänge in derselben Sekunde statt. => machte keinen Unterschied

• Importieren Sie Festplatten auf einen anderen Host, um zu überprüfen, ob die Poolfragmentierung oder die Festplatten fehlerhaft sind => hat keinen Unterschied gemacht
• Verschieben Sie Daten und Root-Pool auf einen identischen Computer, um Verkabelung, Mainboard usw. auszuschließen. => Das Problem besteht weiterhin. Es muss sich also entweder um den Root-Pool (Software) oder um eine bestimmte Hardware handeln, die nicht mit der Software kompatibel ist (oder plötzlich nicht mehr kompatibel ist). ..)

Könnten Sie noch etwas vorschlagen, das die Ursache für dieses Verhalten ist? Oder haben Sie etwas Ähnliches erlebt? Da ich online nichts hilfreiches finden konnte, vermute ich, dass es sich entweder um ein seltsames Hardwareproblem handelt (da es auf einen Computer beschränkt ist) oder um ein Problem mit Windows / Office.

Lösung:

Das Problem betrifft nur OmniOS r151018, nicht frühere Versionen. In diesem Thread auf der Omnios-Discount-Mailingliste ging es genau um mein Problem, Zitat von Geoff:

Ich habe einen ähnlichen Thread mit dem Nexenta-Forum gesehen. Es scheint ein Problem mit Opslock zu geben. Ich habe Opslock deaktiviert und wir sind jetzt gut.

svccfg -s network/smb/server setprop smbd/oplock_enable=false

Ich bin mir nicht sicher, warum dies nicht mehr Menschen beißt.

Also biteCount++;denke ich. Das Problem wurde gelöst, indem das Update angewendet und ein schneller Neustart durchgeführt wurde.

Lektionen für die Zukunft: Verwenden Sie vor dem Versuch einer Fehlerbehebung einfach die erweiterte Suche in den offiziellen Mailinglisten, da Ihr Problem höchstwahrscheinlich bereits auf dem Computer eines anderen aufgetreten ist. Starten Sie außerdem eine schnelle VM, um Software-, Update- oder Konfigurationsfehler auszuschließen, bevor Sie nach Hardwarefehlern suchen.

Wie ich dorthin gekommen bin:

Nach mehreren verschiedenen Tests, wie in der aktualisierten Frage gezeigt, habe ich sie entweder auf Softwareprobleme oder auf Hardware- / Treiberkonflikte auf der spezifischen Hardware eingegrenzt. Um die zweite auszuschließen, habe ich zwei neue virtuelle OmniOS-Maschinen, r151018 und r151016, auf einem anderen Host installiert und auf jeder von ihnen eine grundlegende SMB-Freigabe von Hand konfiguriert.

Der r151018 hat das Problem festgestellt, r151016 funktioniert einwandfrei. Ich vermute, ich habe es bei meinen ersten Tests nicht bemerkt, da ich nur einige Updates auf r151018 zurückgesetzt habe, nicht auf eine frühere Version. Ich denke, das Problem muss länger bestanden haben, als ich angenommen habe.

Auf der Suche nach einer Möglichkeit, Pakete nur einzeln zu aktualisieren, habe ich mir die Mailingliste angesehen und nach smbden letzten 6 Monaten gesucht , in denen die richtige Lösung / das gleiche Problem aus dem Mai aufgetaucht ist.