【操作系统】【读书笔记】磁盘IO调度

磁道

• 单磁道：只有一个磁道，磁道有多个扇区，每个扇区512字节，只有旋转延迟

• 多磁道：一般的磁盘都有数以百万计的磁道，有寻道延迟和旋转延迟

  • 寻道和旋转是磁盘最耗时的操作
    

缓存

• 后写缓存：磁盘驱动器在数据写入缓存后即报告写入成功
  • 看起来更快，但是在对顺序有要求的情况下可能出错！
• 直写：写入磁盘后才报告写入成功
• 补充：善用量纲分析，可以极大简化运算的时候要动的脑筋

IO时间

• 磁盘最耗时的操作：寻道和旋转

  • 相比之下，传输真的很快了

• 不同工作负载的性能差异：天差地别

  • 随机工作负载：磁盘请求的位置随机

  • 顺序工作负载：磁盘请求连续、大块的读写

  • 性能差异（以Cheetah和Barracuda为例）

    	Cheetah（性能好）	Barracuda（容量大）
    随机工作负载	能达到峰值性能的0.5%	能达到峰值性能的0.3%
    顺序工作负载	几乎能达到峰值性能的100%	几乎能达到峰值性能的100%

• 计算平均寻道时间

  • 多数书籍中使用的平均磁盘寻道时间大约是完整寻道时间的1/3
  • 计算方法：使用平均搜索距离进行模拟（涉及到积分）

磁盘IO调度

• 与进程调度的区别：磁盘io在做之前就可以很好地猜测出这次io操作需要多长时间，因此可以实现性能更好的调度
  • 基本思想：贪心的同时避免饿死
• SSTF：最短寻道优先（只考虑寻道）
  • 原理：先处理最近的请求
  • 问题：操作系统不知道磁盘的具体物理结构，无法判断最近的磁道是什么请求
    • 解决：NBF算法，选择最近块号的请求，而不是最近磁道（实际上效果一样，因为块号是顺着磁道排的）
  • 问题：远处请求饿死
    • 本调度无法解决
• 电梯调度（SCAN、C-SCAN）
  • 思想：模拟电梯运行过程，每次扫描一遍磁盘
  • SCAN：每次按磁道顺序扫一遍磁盘
  • C-SCAN：同SCAN，但是到最远处后掉头往回继续扫描，相当于一去一回
  • 优点：不会饿死
  • 问题：只考虑寻道，没有考虑旋转延迟
    • 一般情况下，寻道的时间和旋转的时间差不多，因此旋转也是要考虑的一大问题
• SPTF：最短定位时间优先
  • 思想：LIVNY定律——总是视情况而定！
    • 有两个请求到来时，视情况（当前磁头位置、待处理请求的磁道和其在磁道上的位置等等）决定谁先被响应
    • “视情况而定”这句话几乎可以回答一切问题，好耶！（但是生活中不要用的太多，xs）
  • 难点：操作系统并不知道精确的磁盘状态信息，难以“视情况”决定
    • 解决：SPTF算法一般都是内置在磁盘驱动器中的，而不是由操作系统来使用的。磁盘驱动器本身知晓磁盘的一切信息，这很好
• 其他调度问题
  • 早期，所有调度全部由操作系统完成。但是现代的模式是：如SPTF等调度内嵌到磁盘驱动器中进行，操作系统再根据其他算法对请求进行一些简单的调度（进行了双重调度）。这意味着磁盘驱动器也越来越复杂了
  • 工作保全和非工作保全方法：在向磁盘发出io请求之前，系统需要等多久？
    • 工作保全：立即发送
      • 效率不高，但是操作会立刻执行
    • 非工作保全：等待一会儿再发送
      • 等待的过程中可能出现其他的请求，这样就可以对请求进行调度从而提高效率

操作系统的IO调度程序

• 定义：操作系统内核中负责提交IO请求的子系统被称为IO调度程序

• 主要思想：合并和排序请求，从而提高效率

• 主要工作：管理块设备的请求队列

  • 合并：如果两个请求的磁盘扇区相邻，则可以合并为一个请求
    • 合并操作涉及到向前合并和向后合并两种情况，鉴于一般情况下读取文件都是从前往后读，操作系统一般不考虑向前合并的情况
    • 如果两个请求不相邻但是很近，则排序时理论上应该排在一起

• Linus电梯：可以执行合并和排序的IO调度程序。一个请求到来时，大概有下面四种情况：

  1. 如果队列中有一个相邻的请求，那么合并
  2. 如果队列中有等待时间过长的请求，那么新请求插入队列尾部，不进行排序
  3. 如果队列中以扇区方向为序存在合适的插入位置，那么新请求插入该位置（需要保证电梯运行的顺序）
  4. 如果没有合适的位置，新请求插入尾部
  • Linus电梯部分考虑了饥饿的现象，但是并没有解决问题——仅仅是新请求不插队了，但是老请求前面可能还排着很多的请求，不能保证老请求的执行时间
    • 减少饥饿的代价是降低全局效率

• 最终期限IO调度程序

  • 读操作的重要性
    • 一般情况下，程序发完写以后会继续执行其他逻辑（异步），但是发完读请求以后一般都会阻塞等待读的结果才能继续下一步操作（同步），因此读操作的响应时间对系统的性能影响非常重要
    • 更多时候，读请求可能会互相依靠（比如读很多离得很近的文件），这种情况下对读操作的响应时间要求更高
  • 最终期限调度维护三个队列：普通请求队列、读操作FIFO队列、写操作FIFO队列
    • 每个请求会被插入到两个队列中：普通请求队列，读/写FIFO二选一
    • 普通请求队列在插入时会进行排序（同电梯）
    • 如果FIFO队列头部有请求超时，那么最终期限调度会立即从FIFO队列取出该请求进行服务
      • 读和写设置的超时时间不一样，这样可以使得资源偏斜到读请求
        

• 预测IO调度程序

  • 基本上类似于最终期限调度，但是解决了一个小问题：如果系统正在执行一个工作量很大的写操作，这个时候断断续续的来了一些读操作，那么最终期限调度会尽快响应读请求，结果可能导致写操作的效率变得特别低
  • 关键思想：在处理了一次读请求后，不立即返回，而是等待一小段时间再返回。如果这段时间内出现了新的读请求，则继续处理
  • 实现：如果等待的时间内没有读请求到来，那么会对系统性能带来轻微的损耗。故预测IO调度程序采用启发式的方法，跟踪每个应用程序的习惯来决定是否等待、等待多久。一般来说效果都很好！

• 完全公正的排队IO调度程序（CFQ）

  • 目的：为专有工作负荷设计
  • 思想：每个进程都有自己独立的IO队列，系统对所有的进程IO队列以时间片轮转方式进行调度
  • 优点：实现了进程级的公平，将读和写的矛盾转移到了进程内部

• 空操作的IO调度程序

  • 思想：仅实现了合并，不做任何排序操作
  • 用途：用在随机访存的块设备上

最后

以上就是烂漫鲜花为你收集整理的【操作系统】【读书笔记】磁盘IO调度的全部内容，希望文章能够帮你解决【操作系统】【读书笔记】磁盘IO调度所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。