linux块设备总结（四）块设备数据组织

落日映苍穹つ 2022-02-27 14:34 461阅读 0赞

# 回顾 #

在\[<Linux块设备总结（二）>\]\[[https://blog.csdn.net/weixin\_37867857/article/details/88322091][https_blog.csdn.net_weixin_37867857_article_details_88322091]\]中我们讨论初步认识了linux块设备的架构并且讨论了各个层的作用，下面我们讨论一下在Linux块设备的几个重要的块设备的数据组织形式。  
回顾一下\[<Linux块设备总结（二）>\]\[[https://blog.csdn.net/weixin\_37867857/article/details/88322091][https_blog.csdn.net_weixin_37867857_article_details_88322091]\]中的块设备架构的问题，如下图：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zNzg2Nzg1Nw_size_16_color_FFFFFF_t_70]我们在之前的讨论中介绍了块设备的各个层：VFS层，映射层，通用块设备层，IO调度层。所谓VFS层就是VFS文件系统（虚拟文件系统），主要管理着通用的文件IO操作；映射层主要是判断文件所在的块长度以及文件所在磁盘的索引节点，主要是起着从VFS文件系统到物理卷的映射的作用；通用块设备层在知道文件物理块情况下选择磁盘进行读写；IO调度层在已经知道磁盘的情况下选择如何读写这些数据，比如：读写的先后顺序，数据调度的顺序等等等；

# 块设备读取文件的执行过程 #

我们把从硬盘里面读取一个文件分为如下几个部分：

1.read调用过程
    2.VFS层找到文件系统的inode
    3.通过文件inode找到文件的操作(不是单纯的read/write/ioctl etc, 而是读取文件所在的硬盘设备号，所在硬盘的地址，要读取的数据占用磁盘的磁道号)
    4.找到文件所在块设备的block_device(实际上通过bdev文件系统找到文件的bdev_inode结构)；
    5.找到文件所在的磁盘，并对其进行块设备IO操作；

具体操作流程如下图所示：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zNzg2Nzg1Nw_size_16_color_FFFFFF_t_70 1]

# 数据表示 #

本博客主要介绍通用设备层以下的系统的数据组织结构。包括如下两个大方面：

1.块设备，磁盘，分区的数据表示；
    2.从一个磁盘上执行IO请求的请求队列和块IO的数据表示；

如下图是以上两个大方面的数据结构图示：  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zNzg2Nzg1Nw_size_16_color_FFFFFF_t_70 2]  
根据上图我们可以看到，`struct gen_disk`是连接上述两个问题的重要成员，可以说`struct gen_disk`。我们先重点讨论一下这个数据结构，这个数据结构的名称为通用磁盘结构，可以表示LINUX中的一个物理磁盘，可以说linux中的物理磁盘都有一个`struct gen_disk`结构。他是linux中唯一的标示磁盘的结构，也是连接Linux中设备文件和设备驱动的主要结构。  
`struct gen_disk`结构在设备注册的时候会通过slab分配器进行申请并且进行必要的初始化(比如：主设备号，次设备号范围，磁盘名称， 块设备的fops操作等等)。  
在进行磁盘分区的时候也会操作此数据，把记录磁盘分区的指针。  
在进行read读取一个文件的时候也会根据此数据结构先判断文件所在的物理块是否存在，然后进行块IO的操作，把要读取的数据放入请求队列中。

我们分别讨论一下上述两个大方面的问题；

## 1.块设备，磁盘，分区的数据表示以及其关系； ##

在讨论块设备，磁盘，分区的数据表示之前，我们先要分清楚以下概念：块设备，磁盘，分区到底表示什么？  
我们先讨论磁盘和分区，我们知道分区是磁盘上的磁道的一部分（比如：分区0：扇区0-100，分区1：扇区101-200）。一个磁盘可以有多个分区，但是一个磁盘上的分区不能够全部表示一个磁盘，它只能表示一个磁盘上某一个磁道。  
再讨论块设备的概念，块设备从某种意义上来说是一个虚概念、软概念，如果没有`/dev/sdxxx`表示一个块设备我们平时使用的最多的也就是磁盘和分区。所以这个概念并不被大众所接受，但是对于熟悉linux的人来说都知道块设备表示的是/dev目录下面的文件。块设备有广义上和狭义上之分。狭义上的块设备，就是指的是`/dev/sdxxx`的块设备文件；广义上的块设备指的是磁盘对应的块设备结构和分区对应的块设备结构，本文讨论的是指的是指块设备结构，这是一个广义上的概念。

通过在`块设备读取文件的执行过程`章节处描述我们知道表示一个块设备至少需要三个数据结构：

struct block_device      # 广义上块设备表示
    struct gen_disk            # 通用磁盘表示
    struct hd_struct           # 磁盘分区表示

我们从广义上的块设备入手介绍块设备：假如一个磁盘有四个分区，那么我么的块设备结构就有五个。怎么理解呢？我们的磁盘要对应一个索引块设备结构，还有我们的四个分区对应的是被索引块结构，这些分析过于抽象。  
为什么需要这么多个block\_device数据结构呢？  
首先我们从块设备的通用磁盘着手，去分析一下：

1. 每一个物理磁盘都有一个通用磁盘结构，这个磁盘结构下面挂载了多个硬盘结构。
    	也可以这么理解：一个磁盘上所有的分区共用的是一套读写数据代码。那么不能对于每个分区都分配一套单独的驱动，所以就抽象出来了通用磁盘结构。
    	从另外一方面来讲，一个磁盘无论有多少个分区，从分区读取数据的时候都是从磁道开始到磁道末尾顺序读取的（至少这是机械硬盘的原理，从某种程度上减少了机械硬盘的损耗），从经济的角度来讲，把所有要读取的数据按照从磁道号小到磁道号大的顺序排序也是把通用硬盘提取出来的一方面。
    2. 每个通用磁盘的block_device数据结构代表着这个磁盘的总的索引，所有的分区的block_device都指向这个通用磁盘的block_device数据结构（如最后一张图所示）。

## 2.从一个磁盘上执行IO请求的请求队列和块IO的数据表示 ##

经过上一节对于块设备，磁盘，分区的描述，我们对于磁盘分区有了一个大致的了解。现在我们讲解一下磁盘分区的读写过程，上一节中也有所涉及。本节我们更加深入的探讨一下。  
上一节中我们提到了`一个磁盘无论有多少个分区，从分区读取数据的时候都是从磁道开始到磁道末尾顺序读取的（至少这是机械硬盘的原理，从某种程度上减少了机械硬盘的损耗），从经济的角度来讲，把所有要读取的数据按照从磁道号小到磁道号大的顺序排序也是把通用硬盘提取出来的一方面。`也就意味着所有的磁盘分区的读写都是通过`struct gen_disk`结构来读取的，而且读取的数据要保证高效有效的读取。这就意味着我们的通用磁盘结构gen\_disk需要萃练出来一个数据来顺序的安放这些数据。这就有了struct request\_queue数据结构，这个结构的名称为`请求队列`。

1. 假如我们在不同的用户进程读取一个数据，如果没有放入请求队列的话我们如果有五个进程同时读取，那么需要读取五次，也就是磁道要转五次。照磁盘每分钟转5000转来算，我们读取这五次数据耗费了大约60ms,这个时间略长。
    2. 如果我们把这五次的数据放入一个队列按照从小到大的磁道顺序来读取的话磁盘只需要转动一圈就足够了。耗费时间大约12ms,大大减少了五倍。

这就是我们请求队列的原因：  
我们需要尽量短的时间内读取更多的数据来进行排序。  
我们的请求队列如何组织呢？  
每个请求队列里面包含了若干个request数据结构，每个数据结构包含了若干个bio结构。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zNzg2Nzg1Nw_size_16_color_FFFFFF_t_70 3]  
为什么一个request\_queue对应多个request？一个request对应多个BIO结构呢？  
我们对于磁盘的请求可以分为多次，每次对于磁盘的请求的内容可能不同，我们把对于不同类型的请求放入不同的request。每次的请求可能包含磁盘上连续或者不连续的分区，我们把连续的分区放入到相同的bio里面，不连续的分区放入不同的bio里面，然后从小磁道到大号磁道依次读取。这就是我们需要不同的request和bio的原因。  
本章完。

[https_blog.csdn.net_weixin_37867857_article_details_88322091]: https://blog.csdn.net/weixin_37867857/article/details/88322091
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zNzg2Nzg1Nw_size_16_color_FFFFFF_t_70]: /images/20220227/4847867c7ae142b2ad9daffd6067b653.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zNzg2Nzg1Nw_size_16_color_FFFFFF_t_70 1]: /images/20220227/0791b7d08db2400ea6599acc6901db5b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zNzg2Nzg1Nw_size_16_color_FFFFFF_t_70 2]: /images/20220227/b0e0b19ee741433ea1a4f42522284e0d.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zNzg2Nzg1Nw_size_16_color_FFFFFF_t_70 3]: /images/20220227/04d6f77be7114b829baf53d73f4856b6.png