あまりにも多くの読み取り/書き込み操作を実行すると、問題があることが知られているSDカードを実行しているRaspberry Pi 4でBTRFSでManjaro ARMを実行しています。
このため、ライブスナップショットの可能性を犠牲にすることなく、これらの作業を避けたいと思います。これが、BTRFSを実行してこれらのスナップショットを他の場所にバックアップできる唯一の理由です。
私は最近、nodatacowマウントオプションを使用してBTRFSサブボリュームをマウントするときにスナップショットを取ることができることを発見しました。1] [2]、COWを無効にします。また、技術的な理由から、このオプションをシステム全体に提供する必要があることも知っています。サム]。
私が理解したように、COWを無効にすると、メタデータを期待する「正常な」ファイルシステムの動作が行われます。4]は、書き換えるとファイルの内容が常に上書きされることを意味します。しかし、私の経験によると、[2]、後続の書き込みに新しい場所を割り当てながら、各ファイルの現在のバージョンを保存するスナップショットを実行すると、これは本質的にnodatacowであり、新しい書き込みを上書きします。つまり、現在のバージョンとスナップショット（これには2つのバージョンシステムしかありません。通常は簡単に復元できます）
もう1つの欠点は、チェックサムと圧縮を無効にすることです。サム]。
現在の問題を正しく理解していますか？
nodatacowマウントオプションを使用すると、ファイルシステムとスナップショットのサイズ、断片化、およびパフォーマンス（IO操作）にどのような影響がありますか？
ベストアンサー1
btrfsに関連していないことを調査中にこの問題を発見しました。ご質問の一部にお答えいたします。
NodatacowはSDカードの実際の断片化とパフォーマンスにどのような影響を与えますか？
あまり。これは、合理的な書き込みサイズ（削除ブロックサイズにできるだけ近い）が与えられた場合、fsレベルCOWがそうでない場合に発生するブロックデバイスレベルCOWを置き換えるためです。
もちろん重要なのは、SDカードの実際の削除ブロックサイズを知ることです。ただし、ファイルシステムのブロックサイズがメディアの消去ブロックサイズよりも小さくても（このような場合が多い）、かなり良いパフォーマンスが得られます。
ブロックデバイスレベルのCOW /動的摩耗の平準化（SDカードのコントローラチップによって行われます）とfsレベルのCOWの両方が断片化を生成することができますが、これはシーク時間が不足しているため、通常SDカードとSSDの問題とは見なされません。 。
所定の位置への書き込みにクリアブロックサイズが重要なのはなぜですか？
Raspiフォーラムで：https://forums.raspberrypi.com/viewtopic.php?t=11258
ご覧のとおり、削除ブロックのサイズは非常に大きくなります（最大16個）。中サイズこのスレッドの例では）。これは、SDカードに内部/nocow書き込みを実行するときにカードが16Mを消去してから最大16Mを書き込む必要があることを意味します。どんなに多くのデータを使っても。しかし、これは最悪のシナリオです。これは、SDカードとSSDのコントローラが摩耗の平準化を支援するために独自のバージョンのCOWを実行しようとするために発生します。これは、記録するブロックを比較的ほとんど使用されていないフラッシュメディアに再マッピングし、以前に消去されたブロックを再マッピングするためである。
nodatacowによってディスクサイズはどのように変更されますか？
繰り返しますが、多くはありません。いずれにせよ、btrfsの削除は非同期で行われます。つまり、ファイルを削除してもディスクスペースをすぐに他の目的に使用できるわけではありません。代わりに、もう1つのプロセスは、ファイルシステム（通常のボリューム、スナップショットなど）からデータがどのくらいの頻度で参照されているかを確認し、数がゼロに達すると削除することです。これは datacow と nodatacow も同様です。顕著な唯一の違いは、書き込み操作が非常に忙しいビスナップショットファイルがあると同時に残りの空き領域を確認することです。ディスク領域が正しい値に達するにつれて、より多くの遅延が発生する可能性があります。脅威で使用量の多いファイルは、実際に含まれているよりも一時的に多くのメディアスペースを使用できます。
私は何をお勧めしますか？
不要な書き込みを最小限に抑えるには、マウントオプションを使用し、パーティションが書き込みブロックサイズnoatimeと正しく整列していることを確認し、書き込み増幅を防ぐために削除ブロックサイズと整列する方が良いでしょう。その後、一度試してください。 SSDおよびフラッシュメディアのための他のすべての最適化は、かなり標準的なファイルシステムを使用している場合はほとんど必要ありません（大量のデータベースと仮想マシンイメージを除く）。