いくつかのリアルタイムの制約がある C コードを書いています。dd を使用してディスクに書き込める速度をテストしました。
dd if=/dev/zero of=/dev/sdb bs=32K count=32768 oflag=direct
これにより、32K ブロック サイズで 1GB のゼロが /dev/sdb に書き込まれます。
これで約103 MB /秒に達します
今、私はプログラムで似たようなことをします:
open("/dev/sdb",O_WRONLY|O_CREAT|O_DIRECT|O_TRUNC, 0666);
タイムスタンプ値を 32K バッファから /dev/sdb に 10,000 回 (for ループで) 書き込みます。別のタイムスタンプ値を取得し、MB/s で速度を取得するために少し計算を行います。約 49 MB/s です。
dd と同じ速度に達しないのはなぜですか? strace は、私が使用するのと同じ open コマンドを明らかにします。
openddだけでなく、後続readの s およびwrites. 適切なバッファー サイズを使用すると、この種の大きなコピーに大きな違いが生じる可能性があります。/dev/zero最終的な目標がディスクからディスクへのコピーである場合、ベンチマークの良いテストではないことに注意してください。
ddシステムコールにシステムコールを合わせても の速度に合わせられない場合は...まあ、ソースを読んでください。
システムコールを他の人と照合する部分は残しておきます。この答えは、バッファリングの部分についてです。
使用するバッファサイズのベンチマークを試してください。値の範囲を試してください。
Javaを学ぶとき、私は「コピー」の単純なクローンを作成し、それからその速度に合わせようとしました。コードはバイトごとの読み取り/書き込みを行ったため、実際に違いが生じたのはバッファーサイズでした。私はそれを自分でバッファリングしていませんでしたが、指定されたサイズのチャンクをフェッチするように読み取りを要求していました。チャンクが大きいほど、それは速くなりました-ある程度まで。
32Kブロックサイズの使用に関しては、OSがユーザーモードプロセスに個別のIOバッファーを使用することに注意してください。特定のハードウェアで何かをしている場合、つまり、セクターサイズのCD-RWドライブなど、物理的な制限があるデバイス用のドライバーを作成している場合でも、ブロックサイズは話の一部にすぎません。OSにはまだバッファがあります。