索引节点，LBA，逻辑卷，块和扇区之间是什么关系？

我有点不好意思问这个问题，但是我想看一个图表，显示以下内容之间的关系。如果该图还包括在各个层之间进行映射所需的任何变换，那将是很好的。

据我了解，我相信它们之间的关系如下，但是我不确定我的理解是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的错误指南
• C5170讲义-文件的内部表示-Unix文件系统
• 逻辑块寻址
• Ext4磁盘布局

方式tl; dr

您的图表本质上是正确的。

/dev/<device> 档案

我认为开始回答问题的最基本方法是使用什么/dev/<device>文件。假设您有硬盘。该硬盘有一个基于MBR的分区表，它有两个分区，一个分区格式化为ext4，上面有一些文件，另一个分区为LVM设置。请注意，此答案是关于动态设备文件创建的，这意味着您正在使用Linux内核。事情是有点不同的其他Unix系统。

当您插入此硬盘时（或系统在启动时检测到它），将在/dev目录中创建一个设备文件-通常称为/dev/sd*或/dev/hd*（取决于用于连接驱动器的控制器）-*是一个信件。设备文件上的字节本质上线性映射到物理磁盘上的字节：如果使用工具写入设备文件的开头，该数据也将被写入物理磁盘的物理开头。

现在，系统还可以理解分区表，例如MBR和GPT。创建初始设备文件后，将对其进行读取以确定其是否具有分区表。如果是这样，将创建代表这些分区的设备文件。因此，假设调用了原始设备文件/dev/sda，/dev/sda1将创建一个被称为设备文件（代表第一个ext4格式化分区）以及一个/dev/sda2设备（代表第二个LVM分区）。它们以与整个驱动器相同的方式线性映射到其各自的分区-也就是说，如果您使用工具（例如）写入的开头/dev/sda2，则写入的数据将物理写入第二个分区的开头，实际上是中间 整个磁盘，因为这是第二个分区的起始位置。

区块和部门

这是讨论块和扇区的方便时间：这些只是物理磁盘上空间的度量，仅此而已（至少，如果我理解正确的话）。扇区是硬盘上的物理区域。通常为512字节-较新的硬盘驱动器为4 KB。块也是度量单位，几乎总是8 KB。当有人谈论读写块时，这仅意味着他们以8 KB的块读写数据，而不是单独读取数据的每个字节。

文件系统和索引节点

接下来，文件系统和索引节点。文件系统是一个非常简单的概念：在文件系统所驻留的区域的开头（该区域通常是一个分区），在文件系统上有一堆信息。该标头（我相信也称为超级块）首先用于确定应使用哪个文件系统驱动程序来读取文件系统，然后由选定的文件系统驱动程序使用它来读取文件。当然，这是一种简化，但是它基本上存储了两件事（根据fs类型，这可能会或可能不会作为两个不同的数据结构存储在磁盘上）：目录树和索引节点列表。目录树是您执行ls或时看到的内容tree。目录树指出哪些文件和目录是其他目录的子目录。我们知道，文件/目录的父子关系形成了UNIX目录树。

但是目录树仅包含名称。这些名称还与inode编号关联。索引节点编号包含诸如文件的物理位置在磁盘上的存储位置之类的信息。索引节点本身就是没有名称的“文件”。索引节点通过目录树与名称关联。另请参阅什么是超级块，Inode，Dentry和文件？

到目前为止，我们有以下的解释：/dev/sd*文件映射到硬盘驱动器，/dev/sd*#文件映射到分区号#上/dev/sd*。文件系统是磁盘上的数据结构，用于跟踪目录树。它通常保存在分区（/dev/sd*#）中。文件系统包含索引节点；索引节点是代表文件的数字，以及与这些文件关联的数据（它们的名称和在目录树中的位置除外）。

值得注意的是，文件系统通常以块为单位跟踪数据。通常，目录树和inode列表以块而不是字节存储，inode指向磁盘上的块，而不是字节。（这可能会导致文件通常浪费半个空间的问题，因为文件系统分配了整个块，但不需要将整个块用于文件的最后一部分。）

设备映射器

难题的最后一部分是Linux内核中一个非常重要的模块，称为设备映射器（向其中加载modprobe dm）。设备映射器基本上使您可以在/dev/mapper目录中创建另一个设备文件。然后将该设备文件映射到另一个数据源，可能会在此过程中进行转换。最简单的示例是读取文件的一部分。

假设您有一个完整的磁盘映像，并带有分区表。您需要从映像中的一个分区中读取数据，但是您不能仅访问该分区，因为它是全磁盘映像，而不是单分区映像。解决方案是找到分区在映像中的位置，然后创建一个新的设备文件映射到磁盘映像的该部分。这是一个图：

.-------------------.
|  /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

请注意，在图中，与设备映射器关联的转换逻辑是如何利用很少的工具+来操纵读取请求的，因为它在传送带上移动。

现在，我并不是特别想复制该图并为LVM对其进行修改，但是基本上，转换部分可以是任何东西-不仅仅是向前移动字节范围。LVM的工作方式如下：LVM物理范围是LVM的一部分，它位于磁盘上并跟踪数据的位置。可以将其视为LVM的文件系统。在传送带隐喻中，“物理范围”是源文件之一，而转换是LVM在做的事，将逻辑卷（这是传送带上最左边的项）上的请求映射到磁盘上的物理数据。说到...

我对LVM的概念有些生疏，但是IIRC，卷组本质上就像LVM中的磁盘。同样，每个卷组都管理IIRC，RAID级别等。因此，逻辑卷就像一个分区，而逻辑卷实际上就是代表它们的设备文件。您将文件系统和其他东西放在逻辑卷上。

关于设备映射器的一个很酷的事情是，它内置的逻辑可以任意插入数据堆栈中-您要做的就是更改要读取的设备名称。这就是加密分区的工作方式（不是在文件级别起作用的加密方案-那些使用FUSE的方案），这就是LVM的工作方式。目前我无法想到任何其他示例，但是请相信我，设备映射器非常糟糕。

逻辑块寻址

我从未听说过，因此无法提供任何信息。希望有人来编辑这个答案。