問題タブ [defragmentation]

unsignedintのリストがあるとします。いくつかの要素が0に等しく、それらを押し戻したいとします。現在、私はこのコードを使用しています（listは、サイズnのunsignedintのリストへのポインターです。

このタスクを実行するためのより効率的な方法を考えられますか？

スニペットは純粋に理論的なものであり、製品コードでは、リストの各要素は64バイトの構造体です。

編集：私は私の解決策を投稿します。ジョナサン・レフラーに感謝します。

Windows XP、fat32 システム ボリューム上のファイルの最適化に問題があります。デフラグ ツールを作成しているわけではありませんが、ソリューションの一部では、特定のファイル セットをディスク上に連続的に配置する必要があります。これを確実にするために、FSCTL_MOVE_FILE ioctl を使用して、ファイル エクステントをボリューム上の十分なサイズの単一の空き領域エクステントに移動しています。プロセスは次のようになります。

1) ファイルを作成します。

2) ファイルをゼロで埋めます。

3) ファイルが断片化されていることを確認します。断片化されている場合は、FSCTL_GET_VOLUME_BITMAP を使用してボリューム ビットマップを取得し、十分なサイズの空きクラスター チェーンを見つけます。

4) FSCTL_MOVE_FILE を使用して、ファイルを見つかったエクステントに最適化します。

この最後の呼び出しは、NTFS システムと通常のボリュームで正常に機能します。XP の非システム ボリュームも問題ありません。ただし、XP の FAT32 システム ボリュームでは、ほぼ常に INVALID_ARGUMENT (87) エラーが発生します。ファイルはかなり大きく、約 700MB です。ボリュームには約 10GB の空き容量があります。fsctl が失敗した後、エラーが発生する前にファイルの一部が実際に移動されたことがわかります。何度か挑戦しましたが、今のところ50回すべて失敗しています。この方法で大きなファイルを移動すると、以前に解放されていたクラスターがボリューム上の別の何かによって占有されるために失敗する可能性があることを認識しています。しかし、カーネルが存在しない場合、これを軽減する方法がわかりません。私が間違っていること、および/またはどうすれば改善できますか?

複数のスレッドで複数の C ベースの関数 (p/Invoke) を呼び出すプログラムを作成しています。

時々、アクセス違反エラーでプログラムがクラッシュします。私が最初に考えたのは、GC がメモリを最適化し、C 関数が処理していたメモリのチャンクを別の場所に移動したということでした。

私がやりたいのは、GC を機能させながら、メモリを移動 (デフラグ) する部分を無効にすることです。

これを行う方法はありますか？

Windows 7 のデフラグが完了したときに VB.NET プログラムに通知できるイベントまたはその他の手段はありますか (そのため、プログラムは PC にシャットダウンを指示できます)。

私は技術ツールキット プログラムの作成に取り組んでおり、この「ツールキット」に含まれているのは、ローカル ディスクでデフラグを実行するボタンです。現在、このために作成したバッチ ファイルは単純で、基本的な断片化分析を実行するだけです。

これをトリガーするボタンの背後にある C# コードは次のとおりです。

このコードはまさに私が望んでいることを実行します。UAC を呼び出してから、管理者特権でバッチ ファイルを起動します。バッチ ファイルを実行すると、コマンド コンソールに次のような出力が表示されます。

このエラーの原因と修正方法を教えてください。

Windows によって提供される BY_HANDLE_FILE_INFORMATION 構造が NTFS ディスクの最適化の影響を受けるかどうかを知っている人はいますか?
http://msdn.microsoft.com/en-us/library/windows/desktop/aa363788%28v=vs.85%29.aspx

私は現在、ネットワーキングのスライドを読んでいますが、誰かが断片化と再構築の概念を手伝ってくれるかどうか疑問に思っていました.

それがどのように機能するか、つまり、ネットワーク リンクには MTU があるため、データグラムがどのように小さなチャンクに分割されるかを理解しています。ただし、写真の例は私を混乱させます。

これは MSU であるため、最初の 2 つのセクションは 1500 の長さを示していますが、これは、最後のセクションには 1040 ではなく 1000 (合計 4000 バイト) が必要であることを意味するのではないでしょうか? これらの余分な 40 バイトはどこから来たのでしょうか? 私の推測では、前の 2 つのフラグメントは両方とも 20 バイトのヘッダーを持っていたため、この余分な 40 バイトのデータはどこかに移動する必要があり、最後のフラグメントに到着するのでしょうか?

Fragflag は基本的に別のフラグメントがあることを意味するため、最後のフラグメントがゼロになることを除いて、すべてのフラグメントの Fragflag は 1 になります。ただし、オフセットとは何か、またはその計算方法はわかりません。最初のオフセットがゼロなのはなぜですか? 2 番目のオフセットを取得するために、データ フィールド (1480) のバイトを 8 で割ったのはなぜですか? この8はどこから来たのですか？それとは別に、各フラグメントのオフセットがこの値だけ増加すると仮定していますか?

たとえば、最初のフラグメントのオフセットは 0、2 番目は 185、3 番目は 370、4 番目は 555? になります。(370+185)

助けてくれてありがとう！

データグラムとそれらがどのように断片化されるか、つまり元のデータグラムを再構築するために何が使用されるかに関する興味深い質問をされました。

• すべてのフラグメントの ID 番号が同じであることはわかっています。これは、それらがすべて 1 つの大きなデータグラムに属していることを示しています。
• FragFlag が 1 に設定されているということは、途中でさらに多くのフラグメントがあることを意味しますが、FragFlag が 0 のフラグメントは、それが最終フラグメントであることを意味します。

私が見逃していることがもう 1 つあります。それは、フラグメントが元に戻す必要がある順序を知るために、シーケンス番号も使用する必要があるということです。信頼性が低く、転送中にパケットが失われたり、間違った順序で送信されたりする可能性があります。

対照的に、TCP は信頼できると考えられており、パケットが正しい順序で送信されることを保証する最善の方法です。パケットではなくデータグラムを扱っているため、動作が異なるのでしょうか? または、UDP をより「信頼できる」ものにするために作成されたシーケンス番号でした。

助けてくれてありがとう。