状況：

SMB経由でWindowsおよびOS Xゲストにファイルを提供するOmniOS r151018（95eaa7e）を実行している単一のファイルサーバーで、次の奇妙な問題が発生しました。

SMB共有の[名前を付けて保存]ダイアログウィンドウから特定のファイル（.docx、.xlsx、一部の画像）を保存すると、約3〜5秒の遅延が発生し、その後アプリケーションがまったく応答しなくなります。ファイルは正常に保存されます。

この問題はサーバーに何も実行せずに「夜間に」発生しましたが、ユーザーからのクレームは最初の発生からしばらくしか経過していないため、正確な日付を正確に特定することは困難です。サーバーの再起動後、ミラー化されたルートプールの1つのvdevは使用できませんでしたが、綿密な調査ではデバイスに障害は検出されず、プールに再接続されました。問題はまだ解決しません。

いくつかの観察：

• すべてのWindows 7クライアントで発生します
• すべてのファイルサイズで発生します
• アクセス許可に関係なく、このマシンのすべての共有で発生します
• 別のサーバーからiSCSI経由でホストにインポートされたより高速なストレージで発生します
• 通常のコピー速度はGBitイーサネットで110 MB /秒
• データとルートプールは問題ないようです
• 他のファイルサーバーでは発生しません
• ファイルがローカルに保存され、エクスプローラー経由でコピーされた場合は発生しません
• OS Xでは発生しません（OpenOfficeでのみテストできます）
• dmesgNOTICE: bge0: interrupt: flags 0x0 - not updated?さまざまな値を持ついくつかのカウントを示していますが、これは以前のケースでもあり、害はありませんでした

その他のアイデア/計画：

明確なエラーメッセージが見つからないため、原因を探すために試行錯誤を繰り返す必要があるかもしれません。私が検討するいくつかのこと（結果はイタリック体で示されています）：

• BroadcomネットワークカードをIntelカードに交換=>違いはありませんでした
• ルートプールをSATA SSDで置き換えます（現在、3年以上正常に機能していたSLCメモリUSBスティック）=>違いはありませんでした
• 中間のネットワークをチェックします（ハードウェア、サーバーに直接接続）
• WireSharkによるトラフィックキャプチャ：探しているものが正確にわからない場合は難しい
• ソフトウェアの競合を除外するために以前のOmniOSブート環境/バージョンに戻す=>違いはありませんでした
• Windows / Officeの更新をロールバックしてバグを除外する

• :スナップショットからファイル名に（コロン）を含むファイルを削除します。ewwhite =>によって作成されたredditスレッドでのtxgsyncによる提案は違いを生じませんでした

  Windowsの「以前のバージョン」機能が「：」文字を含む自動スナップショットで有効になっている場合、これに似たものを見たことがあります。これで風を撃つだけですが、「：」文字はWindowsファイル名では使用できないため、一見の価値があります。

• ファイルアクセスの監視：shodanshokにより示唆されるように、私が使用DTraceして、このスクリプトは、ファイルアクセスを監視すること。私はすでに開いているファイルを保存している間にそれを使用し、無関係な出力と個人情報を削除しました、そして結果は3つのファイルを中心にしています：

  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
  

  問題が発生していない別のサーバーで同じ手順を実行すると、同様の結果が得られます。

  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
  

  またwalltimestamp、スクリプトにタイムスタンプ（）を追加しましたが、どちらの場合も、すべてのファイル操作は同じ時間に行われます。=>違いはありませんでした

• 別のホストにディスクをインポートして、プールの断片化またはディスクに障害があるかどうかを確認します=>違いはありませんでした
• データとルートプールを同じマシンに移動して、ケーブル接続、メインボードなどを除外します。=>問題は解決しないため、ルートプール（ソフトウェア）またはソフトウェアと互換性のない（または突然互換性がなくなった）特定のハードウェアである必要があります。 ..）

この動作の原因となる他のことを提案できますか？またはあなたは似たようなことを経験しましたか？オンラインで役立つ情報を見つけることができなかったので、ハードウェアの奇妙な問題（1台のマシンに限定されているため）またはWindows / Officeの問題のどちらかだと思います。

解決：

この問題はOmniOS r151018にのみ影響し、以前のバージョンには影響しません。omn​​ios-discussメーリングリストのこのスレッドは、まさに私の問題に関するものでした、とGeoffからの引用です。

Nexentaフォーラムで同様のスレッドを見ました。opslockに問題があるようです。私はopslockを無効にしました。

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

なぜこれがより多くの人を噛まないのか分かりません。

だから、biteCount++;私は推測します。この問題は、修正を適用して高速再起動することで解決されました。

将来への教訓：トラブルシューティングを試みる前に、公式のメーリングリストで詳細検索を使用してください。おそらく、問題はすでに他の誰かのマシンで発生しているためです。また、ハードウェアエラーを探す前に、クイックVMを起動して、ソフトウェア、更新、または構成エラーを除外します。

私がそこに着いた方法：

更新された質問に見られるようにいくつかの異なるテストを行った後、ソフトウェアの問題または特定のハードウェアでのハードウェア/ドライバーの競合のいずれかに絞り込みました。2番目を除外するために、2つの新しいOmniOS仮想マシンr151018とr151016を別のホストにインストールし、それぞれに基本的なSMB共有を手動で構成しました。

r151018で問題が発生し、r1​​51016は正常に機能します。最初のテストでは気付かなかったのではないかと思います。以前のリリースに戻さずに、r151018の更新の一部のみをロールバックしたためです。問題は私が思ったよりも長く存在したに違いないと思います。

パッケージを1つずつ更新する方法を探すとき、メーリングリストを見て、smb5月からさかのぼって正しい解決策/同じ問題が現れた過去6か月から検索しました。