2

a.dat1GBのファイルがあり、ディスク上にあります。パフォーマンス上の理由から、新しいファイルを作成してファイルを拡張するのではなく、このファイルを再利用して必要に応じてその内容を上書きするだけです (拡張操作ごとに inode のサイズを更新する必要があります)。

私はさらにパフォーマンスを絞り込もうとしており、man ページでopenとmountを検索して、ファイルの mtime と ctime がいつ更新されるかを調べました。私の理解では、ファイルの内容を変更するたびに、mtime や ctime が更新されます。これが xfs の仕組みですか?

もしそうなら、Linuxでこれを無効にする方法はありますか? 私は mtime と ctime を気にせず、書き込み操作ごとにそれらを更新するコストを負担したくありません。

最終的には、ファイルシステムを完全に取り除き、デバイスに直接書き込みますが、当面はファイルシステムでこれを行う方法があることを願っています。

回答に応じて編集

明確にするために、私はSSDに書き込んでおり、SSDから可能なすべての操作を絞り出すことが非常に重要です。SSD は理論的には 1 秒あたり 25,000 の操作を処理できますが、これらのそれぞれが私にとって重要です。ファイルへの書き込み以外にそれらを無駄にしたくありません。その点で、実際には、書き込み先のディスクに 1GB のファイルが 200 個あります。上記の質問で問題を単純化しようとしていました。

さらに、各書き込みは同期する必要があり、ビットがディスク上にあることを確認するまでプログラムは続行されません (これは可能です)。しかし、このメモは質問に接していると思います。

4

1 に答える 1

3

man 2 statmtime と ctime のセマンティクスについては、を参照してください。実際には、mtime と ctime は inode のメモリ内コピーで更新され、非同期的にディスクにフラッシュされます。

主要なカーネル ハッカーがなければ、inode の mtime 更新をスキップすることはできません。ある 32 ビット カウンターから別のメモリ ロケーションへのコピーが速度を落としていると本当に思っている場合は、誤って の高速な部分を最適化しようとしていますwrite(2)。

1GB ファイルのファイル書き込みパフォーマンスを向上させたいですか? ブロック キャッシュが使用するメモリを追加し、mtime を忘れます。

コメントに応じて追加

ディスク書き込みの途中で電源コードを引っ張っても同期は役に立たないため、同期書き込みは意味のある意味での安全性を提供しません。これが、xfs や ext3+ などのジャーナリング ファイルシステムが使用される理由です。期待できる最善の方法は、失敗に直面したときの一貫性です。

ビットがコミットされる前に何かが常に失敗する可能性があるため、バッテリーでバックアップされた SRAM 書き込みバッファーを使用して RAID を構築したとしても、記録されたデータが石にキャストされているという確実性を望んでいるようです。raw ボリュームを書き込むと、ジャーナリングされたファイルシステムよりもさらに保護が少なくなります。

質問で設計意図を明確にすると、より良い答えが得られる可能性があります。直観的なレベルでは、書き込み時間が長くても、小さな 1GB ファイルの場合、フラッシュ メモリは回転する酸化物よりも故障しにくいと思いますが、これは正式な宣言ではありません.

于 2011-06-25T15:23:13.137 に答える