簡単な紹介
シンボリュームについては、 以前の記事ですでに書いています 。 パフォーマンスは良好で、画像の数にわずかに依存します。1年以上、LVMによる障害はなく、すべての問題は私の愛する人のために私が個人的に作成したものです。
すくい
シンボリュームの使用を開始する場合は、 man lvmthinを中毒で読むことを強くお勧めします。 ボリュームプール内の場所が終了する可能性があるという一見重要ではない側面の省略は、悲しい結果につながる可能性があります。
データスペースのスペース不足：
FSに依存します。 通常、ioがフルボリュームで停止した後、FSがジャーナルされている場合は特に、FSがそのまま残ります。 プールを拡張できた場合、io-operationsにタイムアウトまでの時間がありませんでしたが、一般的にはすべて問題ありません。 それ以外の場合は、ロールバックとわずかなデータ損失を記録します。
メタデータスペースのスペース不足：
これは、プールデータの整合性をオフラインで復元する必要があるため、シンプール全体の正しい動作が停止するため、非常に馬鹿げた状況です。 これにより、データ領域で重大な違反が発生することが多く、3つのうち2つのケースでは、復元しようとするよりもXFSを強制終了してバックアップをロールアップする方が簡単でした。
推奨事項：
シンボリュームを自動的にグローバルに拡張するポリシーを設定します。 適切な値を設定したら、プロファイルを使用して、プールの他のポリシーを構成できます。 ただし、システムがプロファイルを適用しない場合（削除できるプロファイルの名前はプールメタデータに保存されます）、ログのどこかにこの事実を報告します（気づかないかもしれません）が、グローバルな政治のおかげで、すべてが比較的良好です。
LVM Thin Provisionは、怠planningな計画の状況でうまく機能します。 これは、さまざまなタスクが合理的に小さなサイズのシンボリュームのプールを作成する必要があることを意味します。 これらのプールにボリュームを作成し、満杯になるとプールのサイズがどのように増加するかを見てください。 場所をすぐに割り当てることは価値がありません。どの場所が必要かを常に予測することはできません。
タスクに基づいてチャンクサイズのサイズを設定します。 サイズを大きくすると、メタデータのオーバーヘッドが低くなりますが、イメージ内のスペースの消費が大きくなります（RAID5-6と一致する場合はボーナスがあります）。
ゼロ調整-オフにすると、速度ボーナスが少し得られますが、準備ができたら、選択したブロックにあらゆる種類のゴミが存在する可能性があります。
スナップショットを使用する
スナップショットは問題なく作成されますが、それを使用すると問題が発生する可能性があります。 問題は、ボリュームがアクティブである間（使用されていませんが）、スナップショットは次のアクティブ化まで適用されない（またはレイジーモードで適用される）ということです。 したがって、スナップショットをローリングする前に、ターゲットボリュームを非アクティブ化します。
デフォルトでは、スナップショットは非アクティブ化フラグを使用して取得されます。 これは、接続しようとすると思いとどまることがあります。