パスではなくUUIDでLVをマウントする利点はありますか？
fstabでマウントを指定できることを知っています（/dev/sda1や/dev/mapper/myvg-logicalVolume1などの）パスを指定するか、fsラベル（LABEL=root）またはUUID（UUID=1234-5678-...）を使用します。
/dev/sda1のような「クラシック」パーティションにUUIDを使用すると、信頼性の点で明らかな利点があります。ドライブのパーティションを再作成したり、ディスクを追加したり、ディスクを追加したりすると、一部のパーティションが別の名前で認識されるようになる可能性があるためです。 、ただしUUIDでマウントすると、データが格納されているパーティション/ LVを特定するのが難しくなります。
しかし、LVMを使用すると、LVMシステム自体がディスク/パーティションの検出を管理し、一部のPVが（パーティション/ディスクで遊んだ後）別の名前になっている場合は問題ではないことがわかります。したがって、（信頼性といえば）UUIDによるマウントや/dev/mapper/vg-lvのようなパスの使用に違いはなく、後者はより明確です。
これは正しいです？
そのとおりです。
UUIDによるマウントは、別のドライブを挿入した場合に/dev/sda1が変更されるなどのパーティション名の古い問題を回避する1つの方法です。
device-mapperは永続的にLVMボリュームに/dev/mapper/vg-lvという名前を付けるので、基盤となるストレージへの変更に関係なく、この抽象化された名前を信頼して同じままにすることができます。
フレンドリ名を使用せずに（device-mapper-multipath）、またはフレンドリ名とバインディングファイルを使用して（/dev/mapper/WWID）、/dev/mapper/mpath0で処理されるデバイスにも同じことが言えます。
後でボリュームグループまたは論理ボリュームの名前を変更したい場合にのみ、自分の足を撃ちます...（lvrenameまたはvgrename）。
Vgまたはlvの名前を変更した理由を忘れると、アクションによってマウントとエクスポートが台無しになります。
LVUUIDは、vgおよびlv renameコマンドを介して永続性を維持します。
特に多数のエクスポートとマウントを担当する場合は、この理由だけでUUIDを使用することをお勧めします。
SANストレージを使用する環境では、これは悪い考えです。テープへの完全バックアップを実行し、新しいハードウェアで復元を実行すると、UUIDはハードウェア駆動型であるため、システムはすべてのUUIDが異なるため、起動します。