結論
btrfsのマウントオプションで圧縮レベルが設定できるからといって使ってはいけない。compress-force=zstd:7でディスク使用量削減は諦めた。
結論に至った経緯
ローカルに保存した画像ファイルが何故か読み込み不能で開けなくなる問題に遭遇した。ブラウザではちゃんと表示されているためネット環境が悪くて正常にダウンロードできなかったのか思って何度か
curl -o temp.jpg https://*****/***.jpg
を実行して保存してみたが開けない。
もしかしてディスクの寿命かなと思って/dev/shm/上に保存して見ると開けたが不思議なことに他のファイルはローカルに正常に保存できる。
特定のファイルのみが何回やっても正常にディスクに保存できないという状態で
バイナリエディタで壊れたファイルを開くとファイルの先端0x20000まで0x00で埋まっていてリブートするとファイルサイズが0になる。
これらの特徴からファイルシステムがぶっ壊れたと思ってググってファイルシステムを調べるコマンドを実行してみたがエラー無し。
ファイルの先端だけ潰れる処理って何なんだろうと考えると何らかの処理をしている途中で処理がコケた場合、出力先にまだ何も出力していない段階なら0x00なのではと考えて圧縮処理を疑ったら正解だった。
fstabからcompress-force=zstd:7を除去すると今までの異常は何だったのかと思えるくらい正しく動作した。
正常に動作するしないの境界選り分ける作業を追加で行った
ファイルが壊れる
- compress-force=zstd:7
ファイルが壊れない
- compress-force=zstd:3
- compress-force=zstd (圧縮レベルはデフォルトでは3で上と同じ)
- 圧縮オプションなし
このテストの結果、高圧縮設定にすると何故かファイルが壊れることが分かった。
圧縮レベルを変えただけなのにファイルが壊れるって不思議だな。