5

クライアントサーバーAで実行されているアプリは、以下を使用してサーバー2008R2ファイルサーバー上にファイルを作成します。

CreateFile(LockFileName,
                  GENERIC_READ or GENERIC_WRITE,
                  FILE_SHARE_READ, nil,
                  CREATE_ALWAYS,
                  FILE_FLAG_WRITE_THROUGH or FILE_FLAG_DELETE_ON_CLOSE,
                  0);

クライアントは災害状況をテストし、「サーバーA」の電源をオフにしてからオフにします。彼らは、同じファイル名と上記の同じコードフラグメントを使用して「サーバーB」で実行されているアプリが少なくとも15分間失敗する（つまり、ファイルが存在し続ける）と報告しています。その時点でファイルは自動的に削除されます。

作成中のサーバーがなくなったこの状況で、これがどのように動作するかを知っている人はいますか？ハンドルを解放してファイルを自動的に削除する必要がありますか？そして、なぜファイルを見るとファイルが削除されるのですか？

興味深いことに、別のおそらく同様の設定では、問題は発生しません。

4

3 に答える 3

4

[...] 作成中のサーバーがなくなった場合、ハンドルを解放してファイルを自動的に削除する必要がありますか?

最終的にはそうですが、すぐにはできません。Windows Server 2008 R2 を実行しているため (したがって SMBv2 です。サーバーとクライアントの両方が Windows Server 2008 R2 で実行されていると想定していることに注意してください)、クライアントは永続的なファイル ハンドルを要求します。SMBv2仕様のセクション 3.3.6.2 および 3.3.7.1 に従って、サーバーは永続的なオープン スカベンジャー タイマーを開始する必要があります (Windows サーバーでは既定で 16 分に設定されています)。タイマーが切れると、サーバーは開いているすべてのハンドルを調べ、クライアントによって再利用されていないハンドルを閉じる必要があります。

もちろん、あなたのシナリオでは、説明によるとクライアント（つまり、プロセスだけでなくサーバー全体）がすぐに強制終了されるため、サーバーがクライアントへの接続損失をまったく検出するかどうかという未解決の問題があります。

ここで、永続的なタイムアウトがまだ実行されている間に別のクライアントがファイルを開こうとしていると仮定します/サーバーはまだファイルが最初のクライアントによって開かれていると見なします。次に、最初にファイルを開いたクライアントに oplock ブレーク通知 (セクション 2.2.23.1) を送信することになっています。クライアントが応答できない (強制終了された) ため、サーバーは、新しいクライアントにファイルへのアクセスを許可する前に、oplock ブレーク確認タイムアウト (セクション 3.3.2.1、デフォルトで 35 秒) が切れるのを待ちます。

注意すべきもう 1 つの点があります。2 番目のクライアントが UNC パスではなくローカル パスを介してファイルにアクセスする場合、動作が異なります。この場合、クライアントは oplock break ack タイムアウトが発生するのを待つ必要はありません。Windows は、最初のクライアントにクローズ要求を送信しようとしている間、ファイルへのアクセスを直ちに許可します。

これは、システムがどのように動作することになっているかです。説明されている問題が発生している理由については、私にはわかりません。Win Server 2008 の Fileserver 実装のバグに遭遇したとしても驚かないでしょう。他の回答で言及されているツールを使用して問題のトラブルシューティングを試みます (procmon は非常に優れています)。Wireshark も大いに役立ちます。 .

于 2012-02-12T03:09:43.413 に答える
1

作成中のサーバーがダウンしたときに、ハンドルがなくなってはならないことは言うまでもありません。ハンドルを削除するには、何かがその削除を開始する必要があります。サーバーが突然ダウンした場合、サーバーはそのハンドルを削除できないため、これらのハンドルは開いたままになります。サーバーがまだ稼働している限り、すべて問題なく、ファイル ハンドルを強制的に閉じる必要はありません。

実際にファイルハンドルを操作しようとするまで。突然、サーバーはファイル ハンドルのホストがなくなったことに気付きます。これは、ホストとの通信を開始しようとするためです。これを認識すると、ファイル ハンドルが強制的に閉じられます。

したがって、あなたの質問に答えるために、これは完全に予測可能で期待される動作のように思えます。

別の環境でファイル ハンドルがすぐに閉じられる理由は、おそらくそれらのサーバーが常に通信している何かに関係しています。何かがリモート ファイルに絶えずアクセスしているのです。ただし、それは単なる推測です。

アップデート

数年前に Microsoft に買収されたSysinternalsには、プロセスの開いているファイル ハンドルを検索できるProcess Explorerという優れたツールがあります。これは、どのプログラムがファイル ハンドルを更新しているかを判断するのに役立つ場合があります。

Sysinternals にはProcess Monitorもあります。これにより、プログラムがファイル ハンドルに基づいて動作する様子をリアルタイムで確認できます。これは、問題のトラブルシューティングに役立つ別のプログラムになる可能性があります。

編集:ああ、本当に楽しみたいなら、Handleもあります。

于 2012-02-09T04:57:40.210 に答える
0

これは私には問題ではないように見えます。または、Microsoft のプログラミングの外では処理できないものであり、処理すると副作用があるものです。基本的に、クライアントとサーバー間の通信のわずかな中断を考慮し、ネットワーク トラフィックを最適化する必要があります。そのため、サーバーは、クライアントがまだ存在しているかどうかを確認するためだけにクライアントと永続的にパケットを交換できません。

コンピューター プログラミングでは、可能な限りそれを考慮に入れる必要がありますが、クライアント アプリケーションが適切に処理しない限り、そのようなタイムアウトは正常です。主な質問 (まったく答えられていません) は、これがまったく問題であるかどうかです。これまでのところ、「標準的な動作」のように見えます。

ハンドルが解放され、ファイルが自動的に削除された場合、作成サーバーがなくなったこの状況でこれがどのように動作することになっているかを知っている人はいますか?

サーバーはどのように知るのでしょうか?

そして、なぜファイルを見ると削除されるのでしょうか?

おそらく、タイムアウトした更新をトリガーしたのは読み取りであり、最後に、これにより定義された動作 (DELETE_ON_CLOSE) がトリガーされました。

ファイルの特定の要素へのアクセスがこれをトリガーすることをほのめかしますが、テスターはエクスプローラーを更新するだけでそれを行いませんでした。

于 2012-02-05T12:39:09.660 に答える