bio，request，request_queue的关系

通用块层的核心数据结构称为bio描述符，它描述了块设备的io操作。每一个bio结构都包含一个磁盘存储区标识符（存储区中的起始扇区号和扇区数目）和一个或多个描述与IO操作相关的内存区段（bio_vec数组）

bio结构中的字段

/*
 * main unit of I/O for the block layer and lower layers (ie drivers and
 * stacking drivers)
 */
struct bio {
	struct bio		*bi_next;	/* request queue link 链接到请求队列中的下一个bio*/
	struct block_device	*bi_bdev;  /* 指向块设备描述符的指针 */
	unsigned int		bi_flags;	/* status, command, etc bio的状态标志*/
	int			bi_error;
	unsigned long		bi_rw;		/* bottom bits READ/WRITE, I/O操作标志（低位是读写位，高位是优先级）
						 * top bits priority
						 */

	struct bvec_iter	bi_iter;

	/* Number of segments in this BIO after
	 * physical address coalescing is performed.
	 */
	unsigned int		bi_phys_segments;  //合并之后bio中物理段的数目

	/*
	 * To keep track of the max segment size, we account for the
	 * sizes of the first and last mergeable segments in this bio.
	 */
	unsigned int		bi_seg_front_size;  
	unsigned int		bi_seg_back_size;

	atomic_t		__bi_remaining;

	bio_end_io_t		*bi_end_io;  //bio的I/O操作结束时调用的方法

	void			*bi_private;  //通用块层和块设备驱动程序的I/O完成方法使用的指针
#ifdef CONFIG_BLK_CGROUP
	/*
	 * Optional ioc and css associated with this bio.  Put on bio
	 * release.  Read comment on top of bio_associate_current().
	 */
	struct io_context	*bi_ioc;
	struct cgroup_subsys_state *bi_css;
#endif
	union {
#if defined(CONFIG_BLK_DEV_INTEGRITY)
		struct bio_integrity_payload *bi_integrity; /* data integrity */
#endif
	};

	unsigned short		bi_vcnt;	/* how many bio_vec's bio的引用计数器*/

	/*
	 * Everything starting with bi_max_vecs will be preserved by bio_reset()
	 */

	unsigned short		bi_max_vecs;	/* max bvl_vecs we can hold bio_vec数组中允许的最大段数*/

	atomic_t		__bi_cnt;	/* pin count */

	struct bio_vec		*bi_io_vec;	/* the actual vec list 存放段的数组*/

	struct bio_set		*bi_pool; //备用的bio内存池

	/*
		为了避免重复申请少量的bio_vec，使用内联一定数量的bio_vec数组，将它放在bio结构的尾部。
	 * We can inline a number of vecs at the end of the bio, to avoid
	 * double allocations for a small number of bio_vecs. This member
	 * MUST obviously be kept at the very end of the bio.
	 */
	struct bio_vec		bi_inline_vecs[0]; /*一般一个bio就一个段，bi_inline_vecs就
    可满足，省去了再为bi_io_vec分配空间*/
};

bio中的每个段是由一个bio_vec数据结构描述的，bio_vec数据结构如下

//bio段就是描述所要读或写的数据在内存中位置
struct bio_vec{
     struct page* bv_page //指向段在页框描述符的指针
     unsigned int bv_len //段的字节长度
     unsigned int bv_offset //页框中数据的偏移量
} 

bio中的bi_io_vec字段指向bio_vec数组的第一个元素，bi_vcnt则说明了数组当前元素的个数，而bi_max_vecs则限定了数组的长度。
下面两幅图可以很好的说明bio与bio_vec的关系

在通用块层启动一次新的IO操作时，会调用bio_alloc函数分配一个新的bio结构，bio是由slab分配器分配的。内核同时也为bio_vec结构分配内存池。

参考：https://blog.csdn.net/zhufengtianya/article/details/42145985?utm_source=copy

bio与bio段的关系

一个bio可能有很多个bio段，这些bio段可能在内存上不连续（位于不同的页），但他们在磁盘上对应的位置是连续的。一般上层构建bio的时候都是只有一个bio段，可以参考_submit_bh函数。

在块io操作期间bio的内容一直保持更新，例如，块设备驱动在一次分散聚集DMA操作中不能一次完成全部数据的传送，那么bio的bi_idx就会更新来指向待传送的第一个段。

bio，request，request_queue的学习

bio：代表了一个io请求

request：一个request中包含了一个或多个bio，为什么要有request这个结构呢？它存在的目的就是为了进行io的调度。通过request这个辅助结构，我们来给bio进行某种调度方法的排序，从而最大化地提高磁盘访问速度。

request_queue：每个磁盘对应一个request_queue.该队列挂的就是request请求。

具体如下图：(有颜色方框头表示数据结构的名字)

请求到达block层后，通过generic_make_request这个入口函数，在通过调用一系列相关的函数（具体参见我另一篇博客）把bio变成了request。具体的做法如下：如果几个bio要读写的区域是连续的，即积攒成一个request（一个request上挂多个连续的bio，就是我们通常说的“合并bio请求”），如果一个bio跟其他的bio都连不上，那它就自己创建一个新的request，把自己挂在这个request下。当然，合并bio的个数也是有限的，这个可以通过配置文件配置。

对于上段补充一点：上层的一次请求可能跨越了多个扇区，形成不连续的扇区段，那么该请求构造的每个bio对应着一个连续的扇区段。故一个请求可以构造出多个bio。

合并后的request放入每个设备对应的request_queue中。之后设备驱动调用peek_request从request_queue中取出request，进行下一步处理。

这里要注意的是，在实现设备驱动时，厂家可以直接从request_queue中拿出排队好的request，也可以实现自己的bio排队方法，即实现自己的make_request_fn方法，即直接拿文件系统传来的bio来自己进行排队，按需设计，想怎么排就怎么排，像ramdisk,还有很多SSD设备的firmware就是自己排。（这里就和我另一篇博客，说到为什么generic_make_request要设计成一层递归调用联系起来）。

网上有个问答也是我的疑惑：这里我写一遍，加强记忆

bio结构中有bio_vec数组结构，该结构的的数组可以指向不同的page单元，那为什么不在bio这一级就做了bio合并工作，即把多个bio合并成一个bio，何必加入一个request这么麻烦？

答：每个bio有自己的end_bio回调，一旦一个bio结束，就会对自己进行收尾工作，如果合并了，或许有些bio会耽误，灵活性差。