私は、データキャッシュを保持しているルートではなくext4ファイルシステムの定期的な破損に対処しています。キャッシングは、特に後で処理しやすいように画像を断片化するために使用される。
アプリケーションログエラー：
OSError: [Errno 74] Bad message: '/redacted/path/to/sliced/image/data'
エラーは次のとおり/var/log/syslogです。
kernel: [163197.788364] EXT4-fs error (device md127): ext4_lookup:1590: inode #125532502: comm python3.6: iget: checksum invalid
ファイルシステムは、3つのSSDを備えたRAID5アレイにあります。
後で実行すると、fsck常に問題が解決します。少なくともこれまで問題が4〜5回発生しました。しかし、実行中のプロセスを再起動するのは明らかに面倒なことであり、この例外（OSError）を無視して他の多くの問題を隠すことは賢明ではないようです。
ファイルが作成された時点（例外が発生する数時間前）を正確に追跡できましたが、/var/log/syslogその時点で問題は報告されませんでした。
ext4ファイルシステムの破損の一般的な原因は何ですか？たとえば、特にPythonで一般的に大きなダメージを引き起こすプログラミングエラー（不適切なロックを使用するなど）は何ですか？カーネルやハードウェアのバグによってシステムログにエラーがないことがよくありますか？
ベストアンサー1
このようなエラー、すべてのエラーは inode チェックサム失敗であると仮定します。、ext4fs モジュールを表します。考えるメタデータが破損しています。もちろん、他のエラーも表示される場合、これは明らかに答えではありません。
Inodeチェックサムエラーは、inode構造に対するext4fs階層のコメントに同意しないいくつかの低レベルのツールまたはモジュール（Pythonではありません！）が原因で発生します。単一ビットを更新しないと、チェックサムエラーが発生します。
完全な inode 操作は、カーネル、ファイルシステムドライバ、および下位レベルのファイルシステム機能間のインタフェースで発生します。これをIOSSまたはI / Oサブシステムと呼びましょう。
このエラーはIOSS / FSのバグかもしれません。これは数年前に起こりました。、xattrがチェックサムと衝突する場合）。したがって、可能であれば、最新のカーネル/ファイルシステムドライバを試すこともできます。