パーティションに直接存在するファイルシステムのオフセットを見つけるのは簡単です。パーティションの開始セクタを確認し、セクタのサイズを掛けて完了します。
ファイルシステムがLVMの内部にある場合はどうなりますか？マジックナンバー、UUIDなどの独自の機能を見つけるためにドライブをスキャンできますが、コンテンツの一致に依存しないことを考えています。
さまざまなブロックデバイスに普遍的なソリューションがありますか？ LUKSコンテナ、dm-integrityなど、データを文字通り保存しないものはどうですか？ブロックデバイスはどんな種類の階層も形成しないと思いますが、答えは「いいえ」でしょうか？
答え1
デバイスマッパー（LVMを含む）に依存するすべては、次のように実行してシステムに設定されているテーブルを表示できるデバイスマッパーテーブルとして表示されます。
dmsetup table
ルートとして。
「単純な」線形マッピングの場合、次のように表示されます。
… 0 67108864 linear 8:0 2048
オフセット2048で始まり、デバイス8：0にマッピングされたブロック範囲があると言います（lsblkデバイスノードと一致するように実行）。
通常、LVM LVは1つ以上のPVに複数の範囲を含めることができるため、オフセットにのみ依存することはできません。
答え2
Stephen Kittの回答で提案されているように、実際のデバイスマッパーテーブルを見ることでこれを行うことができます。
しかし、、この情報はデバイスマッパーテーブルをコピーする以外の目的には役に立ちません。これは、所与の論理ボリュームが単一の基本装置において正しい順序で連続ブロック領域に構成されるという保証がないからである。 RAID設定に関係なく、単一の論理ボリュームが複数の物理ボリュームにまたがる可能性があり、論理拡張領域マッピングに基づいて個々の物理拡張領域が隣接する物理ディスクだけでなく、互いに「正しい」順序であるかをリモートで保証することもできません。 。ゾーン。お互い。
これは、ある物理ボリュームの末尾に最初の16 MBの論理ボリュームを持つことができ、別の物理ボリュームに次の30 GBを持ち、最初の物理ボリュームに次の512 MBを持ち、最初の16 MB前の論理ボリュームを持つことができます。残りのスペースは3番目の物理ボリュームにあります。ファイルシステム「スタート」に関する情報を使って何を計画しても、少なくともいくつかのケースでは動作しないことがほとんど保証されます。