私たちはサードパーティ製のデバイスで動作するソフトウェアを書いています。サポートされているデバイスの1つで、製造元はフラッシュドライブに書き込まないように言った、またはサポートされている制限付き書き込み操作を使い果たす危険がありました。残念ながら、私たちのアプリケーションの要件の1つは、起動中にいくつかのデータを維持することであり、他のオプションはありません。
デバイス内部のドライブが何であるか、どのように構成されているのかわかりません。したがって、1つの質問は、この情報をどのように見つけることができるかということです。私が見つけたいくつかの情報は次のとおりです。
bash-3.2$ df | grep mtd
/dev/mtdblock5 65536 7824 57712 12% /apps
bash-3.2$ dmesg | grep -i mtd
Kernel command line: root=/dev/mtdblock4 rootfstype=jffs2 rw ip=none console= mem=128M init=/sbin/init mtdparts=mtd:512k(bootloader),512k(env),2M(kernel_a),2M(kernel_b),59M(filesystem),64M(user) loglevel=3 panic=5 reboot=h
6 cmdlinepart partitions found on MTD device <NULL>
Creating 6 MTD partitions on "<NULL>":
procとsysfsを見ましたが、役に立つものが見つかりませんでした。デバイス環境には、hdparam、lshwなど、私が見つけることができる便利なツールはインストールされていません。
もう一つの質問は、「書き込み制限」が近づいているかどうかを検出するために使用できる経験的なソフトウェアがありますか？
最後に、悪影響を制限するためにディスクに書き込むときに観察できるベストプラクティスはありますか？たとえば、小さなバースト書き込みが持続書き込み操作よりも優れていますか？データスループットの問題ですか、それともファイルシステムの問題ですか？ファイルを閉じずに開いて、そこにデータを転送することは、それぞれの新しいデータを開いて書いて閉じるよりも優れていますか？
助けてくれてありがとう、ダン。
ベストアンサー1
ファイルを閉じずに開いて、そこにデータを転送することは、それぞれの新しいデータを開いて書いて閉じるよりも優れていますか？
いいえ。バッファリングされた出力のためにファイルを閉じたり閉じたりしないと、ファイルからデータを読み取ることができるかどうかに影響しますが、これはディスクに物理的に書き込まれる場合と同じではありません。
つまり、ファイルハンドルをフラッシュするとき（ファイルハンドルを閉じるなど）、同じファイルから読み取る別のプロセスがファイルにフラッシュしたデータを読み取ることができますが、これは必ずしもファイルが削除されたことを意味するわけではありません。カーネル出力として書かれています。使用している場合は、すでにキャッシュされている可能性があり、そのキャッシュのみが影響を受ける可能性があります。
syncファイルシステム全体で呼び出されると、システムディスクキャッシュがフラッシュされます（->デバイスに書き込まれます）。 AFAIK単一ファイルに対してこれを行う方法はありません。
もう一つの質問は、「書き込み制限」が近づいているかどうかを検出するために使用できる経験的なソフトウェアがありますか？
特にあなたがデバイスについてよく知らないので、これは非常に疑わしいです。これらの数値はおおよその保守的なので、私のイメージングデバイスは通常、事前定義された点で失敗しません。失敗すると失敗します。できるいずれかの時点で失敗した場合は、~N操作まですべてが大丈夫であると仮定するのではなく、結果の損傷を確認して回避するためにできることをすべてお勧めします。
可能な限り実行してくださいfsck（ファイルシステムをマウントする前）。長期実行デバイスの場合は、システムがアイドル状態のときに定期的にマウントを解除してfsckする方法を決定します。