web-dev-qa-db-ja.com

OmniOS / ZFS / Windows 7：アプリケーション内からの「名前を付けて保存」は、CIFS / SMBを超えるすべてのファイルサイズで5秒遅れます

状況：

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

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

この問題はサーバーに何もせずに「一晩」発生しましたが、ユーザーからの苦情は最初の発生からしばらくしてからであるため、正確な日付を特定することは困難です。サーバーの再起動後、ミラーリングされたルートプールの1つのvdevは使用できませんでしたが、詳細な検査でデバイスに障害は検出されず、プールに再接続されました。問題はまだ解決していません。

いくつかの観察：

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

さらなるアイデア/計画：

明確なエラーメッセージが見つからないため、原因を探すために試行錯誤が必要になる場合があります。私が検討するいくつかの事柄（結果はイタリック体）：

  • BroadcomネットワークカードをIntelカードに交換します=>違いはありませんでした
  • ルートプールをSATASSD（現在、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の問題のいずれかであると思われます。

zfsserver-message-blockfile-servermicrosoft-office-2010omnios
9
user121391

解決：

この問題はOmniOSr151018にのみ影響し、以前のバージョンには影響しません。 このスレッド omnios-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つずつ更新する方法を探すとき、私はメーリングリストを見て、過去6か月のsmbを検索しました。ここで、5月にさかのぼる正しい解決策/同じ問題がポップアップしました。

4
user121391