2011-02-02 12 views
3

C#を使用してディスクに大きな(物理的に)連続したファイルを作成することはできますか?管理対象コードのみを使用することをお勧めしますが、不可能な場合はアンマネージドソリューションを評価してください。要するにC#を使用して連続ファイルを作成しますか?

+2

なぜ物理的に連続したファイルが必要だと思いますか?どのような問題を解決しようとしていますか? –

+0

私は一種のnosqlデータベースを構築していますが、ディスクのパフォーマンスは優先されます。 mysql、sqlserverなどのデータベースソリューションは、パフォーマンスを向上させるために常に連続したファイルを使用します。 – tmitchel2

答えて

3

デフラグツールの作成?

あなたはとにかくデフラグAPI後にしているように聞こえる: -

http://msdn.microsoft.com/en-us/library/aa363911%28v=vs.85%29.aspx

リンク下から、あなたが誰かが親切に生産しているのC#ラッパーを見逃しているようだcosを。

http://blogs.msdn.com/b/jeffrey_wall/archive/2004/09/13/229137.aspx

+0

ええ、多分。しかし、C#ではこれをしないでください。 –

+0

正直言って、管理されていませんが、この唯一の解決策は連続したファイルを生成する可能性があることを示しています。 – tmitchel2

0

には、その後

OSは、バックグラウンドでこれを行いません、私は何だろうと、あなたはそれがあることを期待ほどの大きなファイル、OSはcontigouslyそれを配置しますその方法を作るです。ファイルを拡張する必要がある場合は、毎回同じように10%増やします。 これは、SQLサーバーがデータベースファイルをどのように保持するかをシミュレートしたものです。

FileStreamを開くと、appendで開くことができます。

例:

FileStream fwriter = new FileStream("C:\\test.txt", FileMode.Append,  FileAccess.Write, FileShare.Read); 
+0

これは、ハードドライブ上でファイルが連続して書き込まれることを保証しますか?私はそうは思わない。 – Oded

+0

sry、あなたの権利。更新された返信 – EKS

+0

あなたの更新はまだ正しくありません。 OSはディスク上の物理的に連続した位置にファイルを自動的に書き込むのではなく、明示的にデフラグするように指示しない限り、バックグラウンドでファイルを書き込むことはありません(さらに正確なものがどこに行くのか保証されません)。物理的連続性は、OPの要求に対する重要な注意点である。 SQL Serverの実装に関するいくつかの詳細が欠落しています。 –

5

作成した任意のファイルは論理的に連続になります。

物理的に連続したい場合は、OSとFSの領域にあります。通常のI/O APIの制御をはるかに超えた(遠い)。

しかし、おそらく近くに来るのは、スペースを最前面に要求することです:空のストリームを作成し、必要な長さまたは位置のプロパティを設定します。

2

現代のファイルシステムでは、ハードディスク上に連続したファイルを確保することは困難です。論理的にはファイルは常に連続していますが、データを保持する物理ブロックはファイルシステムによって異なります。

これは、古いファイルシステム(ext2、FAT32など)を使用して、必要なファイルサイズにシークしてからこのファイルをフラッシュして大きなファイルを要求することです。より最新のファイルシステムはおそらく大きなファイルサイズをマークしますが、実際にはハードディスクに何も書き込まず、実際には読まなくても将来の読み取りではゼロを返します。

int fileSize = 1024 * 1024 * 512; 
FileStream file = new FileStream("C:\\MyFile", FileMode.Create, FileAccess.Write); 
file.Seek(fileSize, SeekOrigin.Begin); 
file.Close(); 
+0

Askerがこれを最初にやりたい理由は、彼がデータベースを実装しようとしていることを考えると、古いファイルシステムを使用することはできません。 FAT32は、特に4GBの最大ファイルサイズに制限されています。私はext2にも同様の制限があると信じていますが(2GBまたは4GB程度)、そのファイルシステムに関する経験はありませんので、わかりません。また、FAT32が物理的に連続したブロックを返すという保証もありません。 –

+0

あなたはそれについて正しいです。 FAT32は、Ext4、他の現在のファイルシステムのNTFS、特にジャーナルファイルシステムよりもそうする傾向があります。もちろん保証はありませんが、他の人が提案している最適化APIのようなファイルシステムレベルのツールにアクセスすることはありません。これは私ができる最良の提案です。 –

1

データベースを構築するには、スキャッタ・ギャザーのWindows APIが提供するI/O機能を使用する必要があります。これは、ファイルのデータをメモリに「散布」するか、メモリからデータを収集してファイルの連続領域に書き込むことを可能にする特別なタイプのファイルI/Oです。データが散在するバッファまたはバッファから収集されるバッファは連続している必要はありませんが、ソースまたは宛先ファイル領域は常に連続しています。

この機能は、両方とも非同期に動作する2つの主要な機能で構成されています。 ReadFileScatter functionは、ディスク上のファイルから連続したデータを読み取り、それを不連続なメモリバッファの配列に書き込みます。 WriteFileGather functionは、メモリバッファから非連続データを読み取り、ディスク上の連続したファイルに書き込みます。もちろん、これらの機能の両方で使用されるOVERLAPPED structureも必要です。

これは、データベースおよびログファイルの読み取りおよび書き込み時にSQL Serverが使用するもので、実際にはSQL Server用の初期のNT 4.0サービスパックにこの機能が追加されています。

もちろん、これはかなり高度なレベルのものであり、心のかすかなものではありません。意外にも、実際にはpinvoke.netでP/Invokeの定義を見つけることができますが、私はそのサイトに懐疑的な疑念を抱いています。これらの関数がどのように機能するかを理解するためには、ドキュメンテーションに多くの時間を費やす必要があるので、宣言を自分で記述することもできます。そして、C#からやってみると、あなたにはさらに問題のホストがたくさんあります。それで私はそれをお勧めしません。この種のI/Oパフォーマンスが重要な場合は、間違ったツールを使用していると思います。

貧しい人の解決策は、contig.exeです。無料のダウンロードファイルhereが入手可能です。

関連する問題