LVM の危険性と注意事項

LVMに関連するデータ損失を経験した過去に、これについてかなり調査しました。私が認識している主な LVM のリスクと問題は次のとおりです。

VM ハイパーバイザー、ディスク キャッシング、または古い Linux カーネルが原因で、ハードディスクの書き込みキャッシングに対して脆弱です 、ディスク上の構造がより複雑なため、データの回復が難しくなります。詳細については、以下を参照してください。いくつかのディスクで完全な LVM セットアップが破損し、復旧の見込みがないのを見てきました。LVM とハード ディスクの書き込みキャッシュは危険な組み合わせです。

• ハード ドライブによる書き込みキャッシュと書き込みの再注文 良好なパフォーマンスにとって重要ですが、VM ハイパーバイザー、ハード ドライブの書き込みキャッシュ、古い Linux カーネルなどが原因で、ブロックをディスクに正しくフラッシュできない場合があります。
• 書き込みバリアとは、「バリア」ディスク書き込みの前に特定のディスク書き込みを完了することをカーネルが保証することを意味し、突然の停電やクラッシュが発生した場合にファイルシステムと RAID を確実に回復できるようにします。このようなバリアは、FUA (Force Unit Access) 操作を使用して、特定のブロックをディスクに即座に書き込むことができます。これは、フル キャッシュ フラッシュよりも効率的です。バリアを効率的なタグ付き/ネイティブ コマンド キューイング (一度に複数のディスク I/O 要求を発行する) と組み合わせて、データ損失のリスクを増大させることなく、ハード ドライブがインテリジェントな書き込みの並べ替えを実行できるようにすることができます。
• VM ハイパーバイザー 同様の問題が発生する可能性があります:VMware、Xen、KVM、Hyper-V、または VirtualBox などの VM ハイパーバイザー上の Linux ゲストで LVM を実行すると、書き込みキャッシュと書き込みの並べ替えが原因で、書き込みバリアのないカーネルに同様の問題が発生する可能性があります。 . 「ディスクへのフラッシュ」またはライトスルー キャッシュ オプション (KVM、VMware、Xen、VirtualBox などに存在) については、ハイパーバイザーのドキュメントを注意深く確認し、セットアップでテストしてください。 VirtualBox などの一部のハイパーバイザーには、ゲストからのディスク フラッシュを無視するデフォルト設定があります。
• LVM を搭載したエンタープライズ サーバーでは、常にバッテリ バックアップ式の RAID コントローラを使用する必要があります ハードディスクの書き込みキャッシュを無効にします (コントローラには、高速で安全なバッテリ バックアップ付きの書き込みキャッシュがあります)。この XFS FAQ エントリの作成者によるこのコメントを参照してください。カーネルの書き込みバリアをオフにしても安全かもしれませんが、テストすることをお勧めします。
• バッテリ バックアップ式の RAID コントローラがない場合、ハード ドライブの書き込みキャッシュを無効にすると、書き込みが大幅に遅くなりますが、LVM は安全になります。 ext3 の data=ordered に相当するものも使用する必要があります オプション (または data=journal 安全性を高めるため)、プラス barrier=1 カーネルキャッシングが整合性に影響を与えないようにするため。 (または、デフォルトでバリアを有効にする ext4 を使用します。)これは最も単純なオプションであり、パフォーマンスを犠牲にして優れたデータ整合性を提供します。 (Linux はデフォルトの ext3 オプションをより危険な data=writeback に変更しました FS のデフォルト設定に依存しないでください。)
• ハード ドライブの書き込みキャッシュを無効にするには :hdparm -q -W0 /dev/sdX を追加 /etc/rc.local のすべてのドライブ (SATA の場合) または SCSI/SAS の場合は sdparm を使用します。ただし、XFS FAQ のこのエントリ (このトピックに関して非常に優れています) によると、SATA ドライブはドライブ エラーの回復後にこの設定を忘れる可能性があるため、SCSI/SAS を使用するか、SATA を使用する必要がある場合は、約 1 分ごとに実行される cron ジョブの hdparm コマンド。
• SSD / ハード ドライブの書き込みキャッシュを有効に保つ パフォーマンスの向上:これは複雑な領域です - 以下のセクションを参照してください。
• Advanced Format ドライブを使用している場合 つまり、4 KB の物理セクターです。以下を参照してください。書き込みキャッシュを無効にすると、他の問題が発生する可能性があります。
• UPS エンタープライズと SOHO の両方にとって重要ですが、LVM を安全にするのに十分ではありません。ハード クラッシュや電源喪失 (UPS の故障、PSU の故障、ノートパソコンのバッテリー切れなど) が発生すると、ハード ドライブ キャッシュ内のデータが失われる可能性があります。
• 非常に古い Linux カーネル (2009 年の 2.6.x) :2.6.32 以前の非常に古いカーネル バージョンでは書き込みバリアのサポートが不完全です (2.6.31 にはある程度のサポートがありますが、2.6.33 はすべてのタイプのデバイス ターゲットで機能します) - RHEL 6 は多くのパッチで 2.6.32 を使用します。これらの問題に対して古い 2.6 カーネルにパッチが適用されていない場合、ハード ドライブの書き込みバッファにデータが残るハード クラッシュによって大量の FS メタデータ (ジャーナルを含む) が失われる可能性があります (一般的な SATA ドライブの場合、ドライブあたり 32 MB など)。最近書き込まれた 32 MB の FS メタデータとジャーナル データ (カーネルが既にディスク上にあると見なしている) が失われると、通常は多くの FS が破損し、データが失われることを意味します。
• まとめ: LVM で使用されるファイルシステム、RAID、VM ハイパーバイザー、およびハードドライブ/SSD のセットアップには注意が必要です。 LVM を使用している場合は、適切なバックアップが必要です。LVM メタデータ、物理パーティションのセットアップ、MBR、およびボリューム ブート セクターを具体的にバックアップしてください。また、SCSI/SAS ドライブを使用することをお勧めします。これは、キャッシュの書き込み方法について嘘をつく可能性が低いためです。SA​​TA ドライブを使用する場合は、より注意が必要です。

書き込みキャッシュを有効にしておく パフォーマンスのために（そして横たわっている衝動に対処するために）

より複雑ですがパフォーマンスの高いオプションは、SSD/ハード ドライブの書き込みキャッシュを有効に保ち、カーネル 2.6.33 以降の LVM で動作するカーネル書き込みバリアに依存することです (ログで「バリア」メッセージを探して再確認してください)。

また、RAID セットアップ、VM ハイパーバイザー セットアップ、およびファイルシステムが書き込みバリアを使用していることを確認する必要があります (つまり、キー メタデータ/ジャーナルの書き込みの前後に保留中の書き込みをフラッシュするためにドライブが必要です)。 XFS はデフォルトでバリアを使用しますが、ext3 は使用しないため、ext3 では barrier=1 を使用する必要があります マウントオプションで、まだ data=ordered を使用します または data=journal

• 残念ながら、ハード ドライブと SSD の中には、本当にキャッシュをフラッシュしたかどうかについて嘘をつくものがあります ディスク (特に古いドライブ、ただし一部の SATA ドライブと一部のエンタープライズ SSD を含む) へ - 詳細はこちら。 XFS 開発者による優れた要約があります。
• 横たわっているドライブ (Perl スクリプト) の簡単なテスト ツールがあります。または、ドライブ キャッシュの結果としての書き込みの再順序付けをテストする別のツールでこの背景を参照してください。この回答は、ソフトウェア RAID の書き込みバリアの問題を明らかにした SATA ドライブの同様のテストをカバーしていました。これらのテストは、実際にストレージ スタック全体を実行します。
• ネイティブ コマンド キューイング (NCQ) をサポートする最近の SATA ドライブは、嘘をつく可能性が低いかもしれません。または、NCQ により、書き込みキャッシュがなくても適切に動作し、書き込みキャッシュを無効にできないドライブはほとんどありません。
• SCSI/SAS ドライブは、(SATA の NCQ と同様に、SCSI タグ付きコマンド キューイングを介して) 適切に実行するために書き込みキャッシュを必要としないため、通常は問題ありません。
• ハード ドライブまたは SSD がキャッシュをディスクにフラッシュすることについて嘘をついている場合、書き込みバリアに頼ることはできず、書き込みキャッシュを無効にする必要があります。これは、LVM だけでなく、すべてのファイル システム、データベース、ボリューム マネージャー、およびソフトウェア RAID の問題です。

SSD 書き込みキャッシュの使用は SSD の寿命にとって重要であるため、問題があります。スーパーキャパシタを備えた SSD を使用することをお勧めします (停電時のキャッシュ フラッシュを有効にして、キャッシュをライトスルーではなくライトバックにできるようにするため)。

• ほとんどのエンタープライズ SSD は書き込みキャッシュ制御に問題がなく、一部にはスーパーキャパシタが含まれています。
• 一部の安価な SSD には、書き込みキャッシュ構成では修正できない問題があります。PostgreSQL プロジェクトのメーリング リストと Reliable Writes wiki ページは、優れた情報源です。消費者向け SSD には、データ損失の原因となる重大な書き込みキャッシュの問題が発生する可能性があり、スーパーキャパシタが含まれていないため、破損を引き起こす電源障害に対して脆弱です。

高度なフォーマット ドライブのセットアップ - 書き込みキャッシュ、アライメント、RAID、GPT

• 4 KiB の物理セクターを使用する新しい Advanced Format ドライブでは、ドライブの書き込みキャッシュを有効にしておくことが重要な場合があります。そのようなドライブのほとんどは、現在 512 バイトの論理セクターをエミュレート (「512 エミュレーション」) しており、512 を持っていると主張するドライブさえあるからです。 -実際には 4 KiB を使用しながら、バイトの物理セクター。
• Advanced Format ドライブの書き込みキャッシュをオフにすると、アプリケーション/カーネルが 512 バイトの書き込みを行っている場合、パフォーマンスに非常に大きな影響を与える可能性があります。このようなドライブは、単一の書き込みを行う前に 8 x 512 バイトの書き込みを蓄積するためにキャッシュに依存しているためです。 4 KiB の物理書き込み。キャッシュを無効にした場合の影響を確認するために、テストを行うことをお勧めします。
• LVM 物理エクステント (PE) はデフォルトで 4 MiB であるため、LV を 4 KiB 境界に整列させることはパフォーマンスにとって重要ですが、PV の基礎となるパーティションが整列されている限り自動的に行われます。ここで RAID を考慮する必要があります - この LVM およびソフトウェア RAID セットアップ ページでは、ボリュームの最後に RAID スーパーブロックを配置し、(必要に応じて) pvcreate のオプションを使用することを提案しています。 PVを並べます。この LVM メーリング リスト スレッドは、2011 年にカーネルで行われた作業と、単一の LV に 512 バイトおよび 4 KiB セクターのディスクを混在させる場合の部分的なブロック書き込みの問題を指摘しています。
• Advanced Format を使用した GPT パーティショニングでは、最初の LVM パーティション (PV) が 4 KiB 境界で開始されるように、特にブート + ルート ディスクの場合は注意が必要です。

ディスク上の構造が複雑なため、データの復元が困難 :

• ハード クラッシュや電源喪失 (不適切な書き込みキャッシュによる) の後に必要な LVM データの回復は、どう見ても適切なツールがないため、せいぜい手動のプロセスです。 LVM は /etc/lvm 未満のメタデータのバックアップに適しています 、これは LV、VG、および PV の基本構造を復元するのに役立ちますが、失われたファイル システム メタデータには役立ちません。
• したがって、バックアップからの完全な復元が必要になる可能性があります。これには、LVM を使用していないときのジャーナルベースの fsck よりもはるかに多くのダウンタイムが含まれ、最後のバックアップ以降に書き込まれたデータは失われます。
• TestDisk、ext3grep、ext3undel、およびその他のツールは、LVM 以外のディスクからパーティションとファイルを復元できますが、LVM データの復元を直接サポートしていません。 TestDisk は、失われた物理パーティションに LVM PV が含まれていることを検出できますが、これらのツールはいずれも LVM 論理ボリュームを認識しません。 PhotoRec などのファイル カービング ツールは、ファイル システムをバイパスしてデータ ブロックからファイルを再構築するため機能しますが、これは重要なデータに対する最後の手段であり、低レベルのアプローチであり、断片化されたファイルではうまく機能しません。
• 手動で LVM を復元できる場合もありますが、複雑で時間がかかります。復元方法については、この例とこれ、これ、およびこれを参照してください。

ファイル システムのサイズを正しく変更するのが難しい - 簡単なファイルシステムのサイズ変更は、LVM の利点として提供されることがよくありますが、LVM ベースの FS のサイズを変更するには、半ダースのシェル コマンドを実行する必要があります - これは、サーバー全体が稼働している状態で実行でき、場合によっては FS がマウントされた状態で実行できます。しかし、最新のバックアップがなく、同等のサーバーで事前にテストされたコマンドを使用しない限り、後者を危険にさらすことは決してありません (たとえば、運用サーバーの災害復旧クローン)。

• 更新: lvextend の最近のバージョン -r をサポート (--resizefs ) オプション - これが利用可能な場合、特に FS を縮小している場合は、LV とファイルシステムのサイズを変更するためのより安全で迅速な方法であり、ほとんどの場合、このセクションをスキップできます。

• LVM ベースの FS のサイズを変更するためのほとんどのガイドでは、FS が LV のサイズよりもいくらか小さくなければならないという事実を考慮していません:詳細な説明はこちら。ファイルシステムを縮小するときは、FS サイズ変更ツールに新しいサイズを指定する必要があります。 resize2fs ext3、および lvextend の場合 または lvreduce .細心の注意を払わないと、1 GB (10^9) と 1 GiB (2^30) の違い、またはさまざまなツールのサイズの切り上げ方法によって、サイズがわずかに異なる場合があります。

• 計算を正確に行わないと (または、最も明白なステップを超えて追加のステップを使用する場合)、LV に対して大きすぎる FS になる可能性があります。 FS が完全にいっぱいになるまで、何ヶ月も何年も問題ないように見えますが、その時点で深刻な破損が発生します。この問題に気付いていない限り、それまでに実際のディスク エラーが発生する可能性があるため、原因を特定するのは困難です。それは状況を曇らせます。 (この問題は、ファイルシステムのサイズの縮小にのみ影響する可能性があります。ただし、ファイルシステムのサイズをいずれかの方向に変更すると、おそらくユーザーエラーが原因でデータ損失のリスクが高まることは明らかです。)

• LV サイズは FS サイズよりも LVM 物理エクステント (PE) サイズの 2 倍だけ大きくする必要があるようですが、詳細については上記のリンクを確認してください。このソースは正式なものではありません。多くの場合、8 MiB を許可するだけで十分ですが、それ以上を許可する方がよい場合もあります。安全のため、100 MiB または 1 GiB。 4 KiB =4096 バイト ブロックを使用して、PE サイズと論理ボリューム + FS サイズを確認するには:

  PE サイズを KiB で表示:
  vgdisplay --units k myVGname | grep "PE Size"
  
  すべての LV のサイズ:
  lvs --units 4096b
  
  (ext3) FS のサイズ、4 KiB FS ブロックサイズを想定:
  tune2fs -l /dev/myVGname/myLVname | grep 'Block count'

• 対照的に、非 LVM セットアップでは、FS のサイズ変更が非常に信頼性が高く簡単になります。Gparted を実行して必要な FS のサイズを変更すると、すべてが自動的に行われます。サーバーでは、parted を使用できます

• 多くの場合、Gparted Live CD または Parted Magic を使用するのが最善です。これらには、ディストリビューション バージョンよりも最近の、多くの場合、バグのない Gparted &カーネルが含まれているためです。ディストリビューションの Gparted が実行中にパーティションを適切に更新しないために、FS 全体を失ったことがあります。カーネル。ディストリビューションの Gparted を使用している場合は、カーネルのビューが正しくなるように、パーティションを変更した直後に必ず再起動してください。

スナップショットは使いにくく、遅く、バグが多い - スナップショットが事前に割り当てられたスペースを使い果たした場合、スナップショットは自動的に削除されます。特定の LV の各スナップショットは、(以前のスナップショットではなく) その LV に対するデルタであり、重要な書き込みアクティビティ (すべてのスナップショットは以前のものよりも大きい) でファイルシステムのスナップショットを作成するときに多くのスペースを必要とする可能性があります。元の LV と同じサイズのスナップショット LV を作成しても安全です。スナップショットの空き容量が不足することはないからです。

スナップショットも非常に遅くなる可能性があります (これらの MySQL テストでは、LVM を使用しない場合よりも 3 倍から 6 倍遅くなります) - さまざまなスナップショットの問題をカバーするこの回答を参照してください。速度が遅いのは、スナップショットが多くの同期書き込みを必要とするためです。

スナップショットにはいくつかの重大なバグがありました。場合によっては、起動が非常に遅くなったり、起動が完全に失敗したりする可能性があります (LVM スナップショットの場合、ルート FS の待機中にカーネルがタイムアウトする可能性があるため [Debian initramfs-tools で修正済み] 更新、2015 年 3 月]).

• ただし、多くのスナップショット競合状態のバグは 2015 年までに修正されたようです。
• スナップショットのない LVM は、おそらくスナップショットがコア機能ほど使用されていないため、一般的に非常によくデバッグされているようです。

スナップショットの代替 - ファイルシステムと VM ハイパーバイザー

VM/クラウド スナップショット:

• VM ハイパーバイザーまたは IaaS クラウド プロバイダー (VMware、VirtualBox、Amazon EC2/EBS など) を使用している場合、それらのスナップショットは多くの場合、LVM スナップショットよりも優れた代替手段です。バックアップ目的で簡単にスナップショットを作成できます (ただし、そうする前に FS を凍結することを検討してください)。

ファイルシステムのスナップショット:

• ZFS または btrfs を使用したファイルシステム レベルのスナップショットは使いやすく、一般に、ベア メタルを使用している場合は LVM よりも優れています (ただし、ZFS はより成熟しているように見えますが、インストールが面倒です):

• ZFS:数年前から使用されているカーネル ZFS 実装があり、ZFS が採用されているようです。 Ubuntu には、19.10 のルートでの実験的な ZFS を含む、「すぐに使える」オプションとして ZFS が含まれるようになりました。

• btrfs:まだ本番環境で使用する準備ができていません (デフォルトで出荷され、btrfs に専念するチームがある openSUSE でも)、RHEL はサポートを停止しています)。 btrfs には現在 fsck ツール (FAQ) がありますが、壊れたファイルシステムを fsck する必要がある場合は、FAQ で開発者に相談することをお勧めします。

オンライン バックアップと fsck のスナップショット

スナップショットを使用して、一貫したソースを提供できます バックアップの場合、割り当てられたスペースに注意する限り (理想的には、スナップショットはバックアップされる LV と同じサイズです)。優れた rsnapshot (1.3.1 以降) は、LVM スナップショットの作成/削除も管理します - この HOWTO on rsnapshot using LVM を参照してください。ただし、スナップショットに関する一般的な問題と、スナップショット自体をバックアップと見なすべきではないことに注意してください。

LVM スナップショットを使用してオンライン fsck を実行することもできます:LV のスナップショットとスナップショットの fsck を実行しながら、メインの非スナップショット FS を引き続き使用します (ここで説明します)。 'o、ext3 のメンテナです。

スナップショットを作成している間、ファイルシステムを一時的に「フリーズ」する必要があります。ext3 や XFS などの一部のファイルシステムは、LVM がスナップショットを作成するときにこれを自動的に行います。

結論

これらすべてにもかかわらず、私はまだ一部のシステムで LVM を使用していますが、デスクトップのセットアップでは raw パーティションを好みます。 LVM の主なメリットは、FS の移動とサイズ変更の柔軟性です。サーバーの稼働時間を長くする必要がある場合 - それが必要ない場合は、gparted の方が簡単で、データ損失のリスクが少なくなります。

LVM では、VM ハイパーバイザー、ハード ドライブ/SSD 書き込みキャッシュなどのために、書き込みキャッシュの設定に細心の注意が必要ですが、Linux を DB サーバーとして使用する場合も同様です。ほとんどのツールがサポートされていない (gparted 重要なサイズの計算、および testdisk を含む など) 必要以上に使いにくくなります。

LVM を使用する場合は、スナップショットに細心の注意を払ってください。可能であれば VM/クラウド スナップショットを使用するか、LVM を完全に回避するために ZFS/btrfs を調査してください。スナップショットを使用する LVM と比較して、ZFS または btrfs が十分に成熟していることがわかります。

結論:上記の問題とその対処方法がわからない場合は、LVM を使用しないことをお勧めします。

解決策 2:

私はその投稿を [+1] しましたが、少なくとも私にとっては、ほとんどの問題が存在すると思います。数台の 100 台のサーバーと数台の 100 TB のデータを実行しているときにそれらを見ました。私にとって、Linux の LVM2 は誰かが持っていた「賢いアイデア」のように感じます。これらのいくつかのように、彼らは時々「賢くない」ことが判明します。カーネルとユーザー空間 (lvmtab) の状態を厳密に分離していないことは、(コードを正しく理解していないと) 破損の問題が発生する可能性があるため、廃止するのが賢明だと思われるかもしれません。

ええと、この分離には理由がありました - 違いは、PV 損失の処理、および VG のオンラインでの再アクティブ化、つまり、PV が欠落している場合にそれらを元に戻すことで示されます。状態の処理は十分ではありません。Quorum 損失の検出 (笑) や状態の処理 (ディスクを削除しても、使用不可としてフラグが立てられることはありません。それもありません 持っている いまいましいステータス列)

Re:安定性 pvmove ... なぜ

pvmove データ損失

私のブログのこのようなトップ ランキングの記事、うーん?ちょうど今、物理 lvm データがまだ pvmove の途中から状態にハングアップしているディスクを見ています。ユーザースペースからライブブロックデータをコピーするのは悲しいことです.lvmリストからの素敵な引用「vgreduceのようです--missingはpvmoveを処理しません」実際、pvmove中にディスクが切り離された場合、lvm管理ツールはlvmからviに変更されます.ああ、ブロックの読み取り/書き込みエラーの後も pvmove が続行され、実際にはターゲット デバイスにデータが書き込まれないというバグもありました。なんてこと?

Re:スナップショット 新しいデータをスナップショット lv 領域に更新し、スナップを削除した後に再びマージすることにより、CoW は安全ではありません。これは、新しいデータを元の LV に最終的にマージバックする際に IO スパイクが激しく発生することを意味します。さらに重要なのは、もちろんデータ破損のリスクがはるかに高くなることです。壁ですが、オリジナルです。

利点はパフォーマンスにあり、3 回ではなく 1 回の書き込みを行います。高速ではあるが安全でないアルゴリズムを選択することは、VMware や MS のような人々に明らかに期待されることです。「Unix」では、物事が「正しく行われる」と思います。 別のにスナップショット バッキング ストアがある限り、パフォーマンスの問題はあまり見られませんでした プライマリ データよりもディスク ドライブ (もちろん、さらに別のデータへのバックアップも)

Re:障壁 LVMのせいにできるかどうかはわかりません。私が知る限り、これは devmapper の問題でした。しかし、少なくともカーネル 2.6 から 2.6.33AFAIK まで、この問題を実際に気にかけなかったことに責任がある可能性があります。Xen は、仮想マシンに O_DIRECT を使用する唯一のハイパーバイザーであり、使用される問題カーネルがまだそれを使用してキャッシュするため、「ループ」が使用されたときです。Virtualboxには、少なくともこのようなものを無効にする設定があり、Qemu / KVMは通常、キャッシュを許可しているようです。すべての FUSE FS にも問題があります (O_DIRECT はありません)

Re:サイズ LVM は表示サイズの「丸め」を行うと思います。または、GiB を使用します。とにかく、VG Pe サイズを使用し、LV の LE 番号を掛ける必要があります。それは正しいネットサイズを与えるはずであり、その問題は常に使用上の問題です. fsck /マウント（こんにちは、ext3）中にそのようなことに気付かないか、オンラインの「fsck」が機能していないファイルシステムによってさらに悪化します. -n" (こんにちは、ext3)

もちろん、そのような情報の適切な情報源が見つからないことを示しています。 「VRA の LE はいくつですか?」 "PVRA、VGDA などの物理オフセットは?"

元のものと比較して、LVM2 は「UNIX を理解していない人は、それを再発明することを非難される」という典型的な例です。

数か月後の更新:私は今までに、テストの「完全なスナップショット」シナリオに取り組んできました。それらがいっぱいになると、元の LV ではなく、スナップショットがブロックされます。これを最初に投稿したとき、私はそこで間違っていました。ドキュメントから間違った情報を拾ったか、理解していたのかもしれません。私のセットアップでは、私はいつもそれらがいっぱいにならないように非常に妄想的だったので、修正されることはありませんでした.スナップショットを拡大/縮小することもできます。これは便利です。

私がまだ解決できていないのは、スナップショットの年齢を特定する方法です.パフォーマンスに関しては、「thinp」fedoraプロジェクトページに、スナップショット技術が遅くならないように改訂されているというメモがあります.どのように実装しているのかわかりません.

解決策 3:

バックアップにスナップショットを使用する予定がある場合は、スナップショットが存在する場合にパフォーマンスが大幅に低下することに備えてください。そうでなければ、それはすべて良いです。 lvm を使用する主な理由は、アトミック スナップショットではなく、ボリュームを簡単に拡張できないことですが、数年間、数十台のサーバーで運用環境で lvm を使用してきました。

ところで、1TB ドライブを使用する場合は、パーティションの配置について覚えておいてください。このドライブには、おそらく 4kB の物理セクターがあります。

解決策 4:

10年以上前のLVMの状態に関する興味深いウィンドウを提供していますが、受け入れられた回答は現在完全に時代遅れです.モダン (例:2012 年以降の LVM):

• 同期/バリア リクエストを受け入れる
• lvmthin 形式の高速で信頼性の高いスナップショット機能を備えています
• lvmcache による安定した SSD キャッシング dm-writecache による NVMe/NVDIMM/Optane の高速ライトバック ポリシー
• 仮想データ オプティマイザー (vdo ) lvmvdo のおかげでサポート
• lvmraid による統合されたボリュームごとの RAID
• (バージョンに応じて) 1MB または 4MB への自動アライメント。4K アライメントの問題を完全に回避 (ミスアライメント パーティションで LVM を使用しない限り)
• ボリュームを拡張するための優れたサポート、特に 他のブロック デバイスを追加する場合 (プレーン パーティション上で従来のファイルシステムを ext4/xfs として使用する場合、これは単純に不可能です)
• [email protected] の優れた、フレンドリーで非常に便利なメーリング リスト

明らかに、これは常に持っているという意味ではありません LVM を使用するには - ストレージの黄金律は、不要なレイヤーを避けることです。たとえば、単純な仮想マシンの場合、確実に従来のパーティションのみを使用できます。しかし、上記の機能のいずれかを高く評価する場合、LVM は非常に便利なツールであり、真面目な Linux システム管理者のツールボックスに入れておく必要があります。

解決策 5:

アダム、

別の利点:新しい物理ボリューム (PV) を追加し、すべてのデータをその PV に移動してから、サービスを中断することなく古い PV を削除できます。過去 5 年間で少なくとも 4 回はその機能を使用しました。

まだ明確に指摘されていない欠点があります。LVM2 の学習曲線はやや急勾配です。ほとんどの場合、ファイルとその下にあるメディアの間に作成される抽象化の中にあります。一連のサーバーで雑用を分担する少数のメンバーと一緒に作業する場合、チーム全体にとって余分な複雑さが圧倒されることがあります。 IT 作業に専念する大規模なチームでは、通常、このような問題は発生しません。

たとえば、私は仕事で広く使用しており、正しく起動しないシステムを回復するための基本、言語、および最低限必要なことをチーム全体に教えるのに時間をかけました。

特に指摘しておくべき注意点:LVM2 論理ボリュームから起動すると、サーバーがクラッシュしたときに回復操作が困難になることがあります。 Knoppix とその仲間は、そのための適切なものを常に持っているわけではありません。そのため、/boot ディレクトリは独自のパーティションに配置し、常に小さくネイティブにすることにしました。

全体として、私は LVM2 のファンです。