《bio 与 buffer》由会员分享，可在线阅读，更多相关《bio 与 buffer（7页珍藏版）》请在金锄头文库上搜索。
1、bio 与 buffer_head1.概述系统能够随机访问固定大小数据片的设备称为块设备，这些数据片称作块。另一种基本的设备类型是字符设备。字符设备按照字节流的方式被有序访问，像串口和键盘 都属于字符设备。这两种类型的设备的根本区别在于它们是否可以被随机访问，换句话说，就是能否在访问设备时随意从一个位置跳到另一个位置。字符设备仅仅需要控制一个位置-当前位置；而块设备访问的位置必须在介质的不同区间前后移动，同时块设备对执行性能的要求很高。如何管理块设备和如何管理队块设备的请求，该部分在内核中被称为块 I/O 层。2. 解剖一个块设备块设备中最小的可寻址单元式扇区。扇区最常见大小事 512 字节。
2、软件都会用到自己的最小逻辑可寻址单元-块。块文件系统的一种抽象-只能基于块来访问文件系统。虽然物理磁盘寻址是按照扇区级来进行的，但是内核执行的所有磁盘操作都是按照块进行的。所以，块只能数倍 于扇区的大小，但大小不能超过一个页面。扇区：设备的最小寻址单元，亦称硬扇区 或设备块块：文件系统的最小寻址单元，亦称文件块 或I/O 块3.缓冲区和缓冲区头当一个块被调用内存时，它要存储在一个缓冲区中。每个缓冲区与一个块对应，它相当于是磁盘块在内存中的表示。所有这些信息都和文件系统的控制信息密切交融，文件系统的控制信息储存在超级快中，超级块是一种包含文件系统信息的数据结构。由于内核在处理数据需要相关的 控制
3、信息，所以每个缓冲区都有一个对应的描述符。该描述符用buffer_head 结构体表示，被称为缓冲区头，在文 件中定义。结构体中 h_count 域表示缓冲区的使用技术。在操作缓冲区头之前，应该增加缓冲区头的引用计数，确保该缓冲区托不会再被分配出去，当完成对缓冲区的操作后，就减少引用计数。缓冲区头的目的在于描述磁盘块和物理内存缓冲区之间的映射关系。这个结构体在内核中只扮演一个描述符的角色，说明从缓冲区到块的映射关系。 也说明其所描述块的状态 (脏，干净，过期等 )。它并不与底层的块驱动程序打交道。也就是说它现在只是使得内核了解各个块的状态，而当内核需要提交这些块是，就使用 bio， bio 根
4、据 buffer_head 描述的各个块的状态，将相应的块收集起来交给底层驱动程序。因此 bio 现在是上层与下层连接的纽带，它既包含了上层内存的信息，也包含了下层磁盘的信息。在 2.6 内核以前，缓冲区头的作用比现在还要重要。因为缓冲区头作为内核中的 I/O 操作单元，不仅仅描述了从磁盘块到物理内存的映射，而且还是所有块I/O 操作的容器。可是，将 缓冲区头作为 I/O 操作单元带来了两个弊端。首先，缓冲区头是一个很大且不易控制的数据结构体（现在是缩减过的了） ，而且缓冲区头对数据的操作既不方便也不清晰。对内核来说，它更倾向于操作页面结构，因为页面操作起来更为简便，同时效率也高。使用一个巨大
5、的缓冲区头表示每一个独立的缓冲区（可能比页面小）效率低下，所以在 2.6 版本中，许多 I/O操作都是通过内核直接对页面或地址空间进行操作来完成，不再使用缓冲区头了。缓冲区头带来的第二个弊端是：它仅能描述单个缓冲区，当作为所有 I/O的容器使用时，缓冲区头会迫使内核打断对大块数据的 I/O 操作（比如写操作） ，使其成为对多个 buffer_head 结构体进行操作。这样做必然会造成不必要的负但和空间浪费。所以 2.5 开发版内核的主要目标就是为块 I/O 操作引入一种新型、灵活 并且轻量级的容器，也就是要介绍的 bio 结构体。同时也对buffer_head 结构做了简化，让它描述从磁盘块到
6、物理内存的映射信息。而用新定义的为 bio 的结构体作为块 I/O 操作的容器。也既，将原来由 buffer_head 一个结构来完成的工作，现在由 buffer_head 和 bio 共同来完成。现在，buffer_head 只给上层提供有关其所描述的块的当前状态，而 bio 则负责将尽可能多的块合并起来，传递给下层驱动程序，并最终写入硬盘。也即，buffer_head 负责描述磁盘块到物理内存的映射， bio 负责所有块 I/O 操作的容器。 该结构被传递给 I/O 代码，代码会把它合并到一个已经存在的 request 结构中，或者根据需要，再创建一个新的 request 结构。 bio
7、结构包含了驱动程序执行请求的全部信息，而不必与初始化这个请求的用户空间的进程相关联。2.6.29 kernel 关于 buffer_head 前面的注释/* Historically, a buffer_head was used to map a single block* within a page, and of course as the unit of I/O through the* filesystem and block layers. Nowadays the basic I/O unit* is the bio, and buffer_heads are used for
8、extracting block* mappings (via a get_block_t call), for tracking state within* a page (via a page_mapping) and for wrapping bio submission* for backward compatibility reasons (e.g. submit_bh).*/4. bio 结构体目前内核中块 I/O 操作的基本容器由 bio 结构体表示，定义在 中。该结构代表了正在现场(活动)的以片段(segment)链表形式组织的块 I/O 操作。一个片段是一小块连续的内存缓冲区
9、。通过片段来描述缓冲区，即使一个缓 冲区分散在内存的多个位置上，bio 结构体也能对内核保障 I/O 操作的执行。像这样的向量 I/O 就是所谓的聚散 I/O。bio 结构体中最重要的几个域是 bi_io_ves、bi_vcnt、和 bi_idx。总之，每一个块 I/O 请求都是通过一个 bio 结构体表示。每个请求包含一个或多个块，这些块储存在 bio_vec 结构体数组中。buffer head 用来管理每一个文件块，指向 buffer page 所包含的 buffer；每个buffer 包含几个连续的 sector。每个块设备传输的 request 中包含至少一个 bio，每个 bio
10、都包含几 个 bio_vec，每个 bio_vec 都包含一个 segment（ulk3 中这么称呼） ，每个 segment 包含几个连续的 buffer。 要写盘时，通过 buffer_head 为bio 结构体赋值，以保证 io 操作能正确执行。简言之， buffer_head 是用来管理 buffer，而 bio 是用来传输 buffer 的。 bio 为通用层的主要数据结构，既描述了磁盘的位置，又描述了内存的位置，是上层内核 vfs 与下层驱动的连接纽带。 4.1. 缓冲区头与 bio 结构体对比bio 结构体代表的是 I/O 操作，它可以包括内存中的一个或多个页；另一方面，buff
11、er_head 结构体代表的是一个缓冲区，它描述的仅仅是磁盘中的一个块。 bio结构体是轻量级的，它描述的块可以不需要连续存储区，并且不需要分割 I/O操作。利用 bio 结构体代替 buffer_head 结构体的好处：1) bio 结构体很容易处理高端内存，因为它处理的是物理页而不是直接指针2) bio 结构体既可以代表普通页 I/O，也可以代表直接 I/O3) bio 结构体便于执行分散-集中块 I/O 操作4) bio 结构体比缓冲区头属于轻量级的结构体。因为它只需要包含块 I/O 操作所需的信息，不用包含与缓冲区本身相关的不必要信息但是，还是需要缓冲区头这个概念，毕竟它还要负责描述磁
12、盘块到页面的映射。5. 请求队列块设备将它们挂起的块 I/O 请求存在请求队列中，该队列由 request_queue 结构体表示，定义在中，包含一个双向请求队列以及相关控制信息。通过内核中像文件系统这样高层的代码将请求加入到队列中。请求队列只要不为空，队 列对应的块设备驱动程序就会从队列头获取请求，然后将其送入对应的块设备上去。6. I/O 调度程序磁盘寻址是整个计算机中最慢的操作之一，为了优化寻址操作(尽量缩短寻址时间)，内核既不会简单地按请求接收次序，也不会立即将其提交给磁盘。相反，它会在提交前，先执行名为合并与排序的预操作，在内核中负责提交 I/O 请求的子系统称为 I/O 调度程序。
13、I/O 调度程序是将磁盘 I/O 资源分配给系统中所有挂起的块 I/O 请求。具体的说，这种资源分配时通过将请求队列中挂起的请求合并和排序来完成的。而进程调度程 序的作用是将处理器资源分配给系统中的运行进程。进程调度程序和 I/O调度程序都是将一个资源虚拟给多个对象，对于进程调度程序来说，处理器被虚拟并被系 统中的运行进程共享。而 I/O 调度程序虚拟块设备给多个磁盘请求，以便降低磁盘寻址时间，确保磁盘性能的最优化。6.1. I/O 调度程序的工作I/O 调度程序的工作是管理块设备的请求队列。它决定队列中的请求排列顺序以及在什么时刻派发请求道块设备。这样做有利于减少磁盘寻址时间，从而提高全局(
14、可能存在对某些请求不公)吞吐量。I/O 调度程序通过两种方法来减少磁盘寻址时间：合并与排序。合 并指将两个或多个请求结合成一个新请求。当文件系统提交请求到请求队列-从文件中读取一个数据区，如果此时队列已经存在一个请求，它访问的磁盘扇区和当 前请求访问的磁盘扇区相邻，那么这两个请求可以合并为对一个对单个和多个相邻磁盘扇区操作的新请求。因此，合并请求显然能减少系统开销和磁盘寻址次数。假 设在读请求被提交给请求队列的时候，队列中并没有其他请求需要操作相邻的扇区，此时就无法将当前请求与其他请求合并，这是就需要排序。排序就是如果存在一 个请求，它要操作的磁盘扇区位置与当前请求的比较接近，就让这两个请求在
15、队列上也相邻，整个请求队列将按扇区增长方向有序排列。这样，通过保持磁头以直线 方向移动，缩短了所有请求的磁盘寻址时间。6.2. Linus 电梯在 2.4 内核中，Linus 电梯时默认的 I/O 调度程序，它能执行合并与排序处理。合并：当有新的请求加入队列时，它首先会检查其他每一个挂起的请求是否可以和新请求合并。如果新请求正好连在一个现存的请求前，就是向前合并；相反如果新请求直接连在一个现存的请求后，就是向后合并。排 序：如果合并失败，就需要寻找可能的插入点 (新请求在队列中的位置必须符合请求以扇区方向有序排序的原则)。如果找到，新请求就被插入该点；如果没有合适 的位置，就被插入队列尾部。另
16、外，如果发现队列中有驻留时间过长的请求，那么新请求将被加入到队列尾部，即使插入后也要排序。缺陷是该算法并非是给等待了一段时间的请求提供实质服务，这最终会导致请求饥饿现象发生。例如，一个对磁盘同一位置操作的请求可以造成较远位置的其他请求永远得不到运行的机会。6.3. 最终期限 I/O 调度程序最终期限(deadline)I/O 调度程序是为了解决 Linus 电梯锁带来的饥饿问题而提出的。写操作通常是在内核有空时才将请求提交给磁盘的，写操作和提交它的应用程序异步执行；读操作具有同步性，并且彼此之间往往相互依靠，所以读请求响应时间直接影响系统性能。因此，2.6 内核新引入了最后期限 I/O 调用程序。注意，减少饥饿现象必须以降低全局吞吐量为代价。在 最后期限 I/O 调度程序中，每个请求都有一个超时时间。默认下，读请求的超时时间是 500 毫秒，写请求的超时时间是 5 秒。该调度程序有三个队列：一是排序 队列，以磁盘物理位置为次序来维护请求队列。当一个新请求递交给排序队列时，最后期限 I/O 调度程序类似 Lin
