この質問をするのは少し恥ずかしいですが、次のことがどのように関連しているかを示す図を見たいと思います。ダイアグラムに、さまざまなレイヤー間でのマッピングに必要な変換も含まれていると便利です。
私はそれを理解しているので、それらは次のように関連していると思いますが、私の理解が100％正確であるかどうかはわかりません。
.-----------------.
| inode |
'-----------------'
|
.-----------------.
| EXT4 |
'-----------------'
|
.---------------------.
| logical volume (LV) | --- part of LVM
'---------------------'
|
.-------------------.
| volume group (VG) | --- part of LVM
'-------------------'
|
.---------------.
| /dev/<device> |
'---------------'
|
.--------------------------------.
| Logical Block Addressing (LBA) |
'--------------------------------'
|
.-----------------.
| blocks/sectors |
'-----------------'
|
HDD
_.-----._
.- -.
|-_ _-|
| ~-----~ |
| |
`._ _.'
"-----"
参考資料
- ファイルを占めるハードドライブセクターを見つける
- 読み取り不可能なディスクセクターに関連付けられているファイルを特定する
- smartmontoolsの不良ブロックHOWTO
- C5170講義ノート—ファイルの内部表現–Unixファイルシステム
- 論理ブロックアドレス指定
- Ext4ディスクレイアウト
承認された回答：
way tl; dr
あなたの図は本質的に正しいです。
/dev/<device> ファイル
質問に答える最も基本的な方法は、/dev/<device>を使用することだと思います。 ファイルはです。ハードディスクがあるとします。このハードディスクにはMBRベースのパーティションテーブルがあり、2つのパーティションがあります。1つはいくつかのファイルを含むフォーマットされたext4で、もう1つはLVM用にセットアップされています。この回答は、オンザフライのデバイスファイル作成について説明していることに注意してください。これは、Linuxカーネルを使用していることを意味します。他のユニスでは状況が少し異なります。
このハードディスクを接続すると（またはシステムが起動時に検出すると）、デバイスファイルが/devに作成されます。 ディレクトリ–一般的に/dev/sd*と呼ばれます または/dev/hd* （ドライブの接続に使用されるコントローラーによって異なります）–*は文字です。デバイスファイルのバイトは、基本的に物理ディスクのバイトに線形にマッピングされます。ツールを使用してデバイスファイルの先頭に書き込むと、そのデータは物理ディスクの物理的な先頭にも書き込まれます。
現在、システムはMBRやGPTなどのパーティションテーブルも理解します。最初のデバイスファイルが作成されると、それが読み取られて、パーティションテーブルがあるかどうかが判断されます。その場合、これらのパーティションを表すデバイスファイルが作成されます。したがって、元のデバイスファイルが/dev/sdaと呼ばれていると仮定します。 、/dev/sda1というデバイスファイル /dev/sda2と同様に、作成されます（最初の、ext4形式のパーティションを表します）。 デバイス（2番目のLVMパーティションを表す）。これらは、ドライブ全体と同じ方法でそれぞれのパーティションに線形にマッピングされます。つまり、ツールを使用して（たとえば）/dev/sda2の先頭に書き込む場合です。 、書き込まれるデータは、実際には中央である2番目のパーティションの先頭に物理的に書き込まれます。 2番目のパーティションが始まる場所だからです。
ブロックとセクター
これは、ブロックとセクターについて話すのに便利な時間です。これらは、物理ディスク上のスペースの単なる測定値であり、それ以上のものではありません（少なくとも私が正しく理解している場合）。セクターは、ハードドライブ上の物理的な領域です。通常は512バイト–新しいハードドライブでは4KBです。ブロックも測定単位であり、ほとんどの場合8KBです。誰かがブロックの読み取りと書き込みについて話すとき、それはデータの各バイトを個別に読み取るのではなく、8KBのチャンクでデータを読み書きすることを意味します。
ファイルシステムとiノード
次は、ファイルシステムとiノードです。ファイルシステムは非常に単純な概念です。ファイルシステムが存在する領域（この領域は通常はパーティションです）の先頭に、ファイルシステムに関する一連の情報があります。このヘッダー（スーパーブロックとも呼ばれます）は、最初にファイルシステムの読み取りに使用するファイルシステムドライバーを決定するために使用され、次に選択したファイルシステムドライバーがファイルの読み取りに使用します。もちろん、これは単純化ですが、基本的に2つのものを格納します（fsタイプに応じて、ディスクに2つの異なるデータ構造として格納される場合とされない場合があります）。ディレクトリツリーとiノードのリストです。ディレクトリツリーは、lsを実行したときに表示されるものです。 またはtree 。ディレクトリツリーは、どのファイルとディレクトリが他のどのディレクトリの子であるかを示します。ファイル/ディレクトリの親子関係は、私たちが知っているようにUNIXディレクトリツリーを形成します。
ただし、ディレクトリツリーには名前しか含まれていません。これらの名前は、iノード番号に追加で関連付けられています。 iノード番号には、ファイルの一部がディスク上の物理的に保存されている場所などの情報が含まれています。 iノード自体は、名前のない単なる「ファイル」です。 iノードはディレクトリツリーを介して名前に関連付けられます。スーパーブロック、iノード、Dentry、およびファイルとは何ですか？
も参照してください。
これまでのところ、次の説明があります：/dev/sd* ファイルはハードドライブにマップされます、/dev/sd*# ファイルはパーティション番号#にマップされます /dev/sd*に 。ファイルシステムは、ディレクトリツリーを追跡するディスク上のデータ構造です。通常、パーティション（/dev/sd*#）に保持されます ）。ファイルシステムにはiノードが含まれています。 iノードは、ファイルと、それらのファイルに関連付けられたデータ（ディレクトリツリー内の名前と位置を除く）を表す番号です。
ファイルシステムは通常、データをブロック単位で追跡することに注意してください。通常、ディレクトリツリーとiノードリストはバイト単位ではなくブロック単位で保存され、iノードはバイト単位ではなくディスク上のブロックを指します。 （これにより、ファイルシステムがブロック全体を割り当てたが、ファイルの最後の部分にそのブロック全体を使用する必要がなかったため、ファイルが通常半分のブロックのスペースを浪費するという問題が発生する可能性があります。）
デバイスマッパー
パズルの最後のピースは、デバイスマッパーと呼ばれるLinuxカーネルの非常に重要なモジュールです。 （modprobe dmでロードします ）。デバイスマッパーを使用すると、基本的に/dev/mapperに別のデバイスファイルを作成できます。 ディレクトリ。次に、そのデバイスファイルは別のデータソースにマップされ、プロセスで変換される可能性があります。最も簡単な例は、ファイルの一部を読み取ることです。
パーティションテーブルを備えたフルディスクイメージがあるとします。イメージ内のパーティションの1つからデータを読み取る必要がありますが、だけに到達することはできません。 そのパーティションは、単一パーティションのイメージではなく、フルディスクイメージであるためです。解決策は、パーティションがイメージ内のどこにあるかを見つけてから、ディスクイメージのその部分にマッピングする新しいデバイスファイルを作成することです。これが図です：
.-------------------.
| /dev/mapper/foo | <- This is the device file created with the device mapper
.___________________.
/
/
/ <- This is a small section of the image being mapped to
/ the new device file
/
/
.------------------.
| diskimage.img | <- This is the full-disk image. It's a regular file.
.__________________. Notice how the mapping goes to _part_ of the file.
別の考え方は、変換パイプラインのようなものです（これは、カーネルの内部で起こっていることのより正確なメタファーです）。コンベヤーベルトを想像してみてください。要求（読み取り、書き込みなど）は、デバイスマッパーで作成されたデバイスファイルで、コンベヤーベルトの一方の端から始まります。次に、リクエストはデバイスマッパートランスフォーメーションを介してソースファイルに移動します。上記の例では、このソースファイルは通常のファイルdiskimage.imgです。 。図は次のとおりです。
Read operation goes onto
device mapper conveyor belt
read() The device mapper transforms the read The modified read request finally
request by moving the requested region reaches the source file, and the data
Beginning of conveyor belt to read forward by some number of bytes. is retrieved from the filesystem.
.-------------------. .--------------------------. .------------------------.
| /dev/mapper/foo | | Transformation logic | | /path/to/diskimage.img |
.___________________. .___+_____+_____+_____+____. .________________________.
-->
---------------------------------------------------------------------------------------------------------------
o o o o o o o o o o o
この図では、デバイスマッパーに接続されている変換ロジックに小さなツール（+）が含まれていることに注目してください。 s）コンベヤーベルト上を移動する読み取り要求を操作します。
さて、私はその図をコピーしてLVM用に変更する気は特にありませんが、基本的に、変換部分は、バイト範囲を前方にシフトするだけでなく、何でもかまいません。これがLVMの仕組みです。LVM物理エクステントは、ディスク上に配置され、データの場所を追跡するLVMの一部です。 LVMのファイルシステムのように考えてください。コンベヤーベルトのメタファーでは、物理エクステントはソースファイルの1つであり、変換はLVMがその処理を実行し、論理ボリューム（コンベヤーベルトの左端のアイテム）の要求をディスク上の物理データにマッピングします。そういえば…
私はLVMの概念に少し錆びていますが、ボリュームグループであるIIRCは本質的にLVMのディスクのようなものです。この場合も、IIRC、RAIDレベルなどはボリュームグループごとに管理されます。したがって、論理ボリュームはパーティションのようなものであり、論理ボリュームは実際にそれらを表すデバイスファイルを持っているものです。ファイルシステムなどを論理ボリュームに配置します。
デバイスマッパーの優れた点は、それを使用して構築されたロジックをデータスタックに任意に挿入できることです。必要なのは、読み取るデバイス名を変更することだけです。これが暗号化されたパーティションの仕組みです（ ファイルレベルで機能する暗号化スキーム（FUSEを使用）。これがLVMの機能です。現時点では他の例は考えられませんが、信頼してください。デバイスマッパーはかなりひどいです。
論理ブロックアドレス指定
これについて聞いたことがないので、情報を提供することはできません。誰かが来てこの答えを編集してくれることを願っています。