磁道调度

一次磁盘读写操作的时间由寻找(寻道)时间、延迟时间和传输时间决定:

1) 寻找时间Ts:活动头磁盘在读写信息前,将磁头移动到指定磁道所需要的时间。这个时间除跨越n条磁道的时间外,还包括启动磁臂的时间s,即:

式中,m是与磁盘驱动器速度有关的常数,约为0.2ms,磁臂的启动时间约为2ms。

2)延迟时间Tr:磁头定位到某一磁道的扇区(块号)所需要的时间,设磁盘的旋转速度为r,则:

对于硬盘,典型的旋转速度为5400r/m,相当于一周11.1ms,则Tr为5.55ms;对于软盘,其旋转速度在300~600r/m之间,则Tr为50~100ms。

3) 传输时间Tt:从磁盘读出或向磁盘写入数据所经历的时间,这个时间取决于每次所读/写的字节数b和磁盘的旋转速度:

式中,r为磁盘每秒钟的转数;N为一个磁道上的字节数。

在磁盘存取时间的计算中,寻道时间与磁盘调度算法相关,下面将会介绍分析几种算法,而延迟时间和传输时间都与磁盘旋转速度相关,且为线性相关,所以在硬件上,转速是磁盘性能的一个非常重要的参数。

总平均存取时间Ta可以表示为:

虽然这里给出了总平均存取时间的公式,但是这个平均值是没有太大实际意义的,因为在实际的磁盘I/O操作中,存取时间与磁盘调度算法密切相关。调度算法直接决定寻找时间,从而决定了总的存取时间。

目前常用的磁盘调度算法有以下几种:

1) 先来先服务(First Come First Served, FCFS)算法

FCFS算法根据进程请求访问磁盘的先后顺序进行调度,这是一种最简单的调度算法,如图4-25所示。该算法的优点是具有公平性。如果只有少量进程需要访问,且大部分请求都是访问簇聚的文件扇区,则有望达到较好的性能;但如果有大量进程竞争使用磁盘,那么这种算法在性能上往往接近于随机调度。所以,实际磁盘调度中考虑一些更为复杂的调度算法。


图4-25 FCFS磁盘调度算法

例如,磁盘请求队列中的请求顺序分别为55、58、39、18、90、160、150、38、184,磁头初始位置是100磁道,釆用FCFS算法磁头的运动过程如图4-25所示。磁头共移动了 (45+3+19+21+72+70+10+112+146)=498 个磁道,平均寻找长度=498/9=55.3。

2) 最短寻找时间优先(Shortest  Seek  Time  First, SSTF)算法

SSTF算法选择调度处理的磁道是与当前磁头所在磁道距离最近的磁道,以使每次的寻找时间最短。当然,总是选择最小寻找时间并不能保证平均寻找时间最小,但是能提供比 FCFS算法更好的性能。这种算法会产生“饥饿”现象。如图4-26所示,若某时刻磁头正在 18号磁道,而在18号磁道附近频繁地增加新的请求,那么SSTF算法使得磁头长时间在18 号磁道附近工作,将使184号磁道的访问被无限期地延迟,即被“饿死”。


图4-26  SSTF磁盘调度算法

例如,磁盘请求队列中的请求顺序分别为55、58、39、18、90、160、150、38、184,磁头初始位置是100磁道,釆用SSTF算法磁头的运动过程如图4-26所示。磁头共移动了 (10+32+3+16+1+20+132+10+24)=248 个磁道,平均寻找长度=248/9=27.5。

3) 扫描(SCAN)算法(又称电梯算法)

SCAN算法在磁头当前移动方向上选择与当前磁头所在磁道距离最近的请求作为下一次服务的对象,如图4-27所示。由于磁头移动规律与电梯运行相似,故又称为电梯调度算法。SCAN算法对最近扫描过的区域不公平,因此,它在访问局部性方面不如FCFS算法和 SSTF算法好。


图4-27  SCAN磁盘调度算法

例如,磁盘请求队列中的请求顺序分别为55、58、39、18、90、160、150、38、184,磁头初始位置是100 磁道。釆用SCAN算法时,不但要知道磁头的当前位置,还要知道磁头的移动方向,假设磁头沿磁道号增大的顺序移动,则磁头的运动过程如图4-27所示。磁头共移动了(50+10+24+94+32+3+16+1+20)=250 个磁道,平均寻找长度=250/9=27.8。

4) 循环扫描(Circulair SCAN, C-SCAN)算法

在扫描算法的基础上规定磁头单向移动来提供服务,回返时直接快速移动至起始端而不服务任何请求。由于SCAN算法偏向于处理那些接近最里或最外的磁道的访问请求,所以使用改进型的C-SCAN算法来避免这个问题。

釆用SCAN算法和C-SCAN算法时磁头总是严格地遵循从盘面的一端到另一端,显然,在实际使用时还可以改进,即磁头移动只需要到达最远端的一个请求即可返回,不需要到达磁盘端点。这种形式的SCAN算法和C-SCAN算法称为LOOK和C-LOOK调度。这是因为它们在朝一个给定方向移动前会查看是否有请求。注意,若无特别说明,也可以默认SCAN 算法和C-SCAN算法为LOOK和C-LOOK调度。


图4-28  C-SCAN磁盘调度算法

例如,磁盘请求队列中的请求顺序分别为55、58、39、18、90、160、150、38、184,磁头初始位置是100磁道。釆用C-SCAN算法时,假设磁头沿磁道号增大的顺序移动,则磁头的运动过程如图4-28所示。磁头共移动了(50+10+24+166+20+1+16+3+32)=322个磁道,平均寻道长度=322/9=35.8。

对比以上几种磁盘调度算法,FCFS算法太过简单,性能较差,仅在请求队列长度接近于1时才较为理想;SSTF算法较为通用和自然;SCAN算法和C-SCAN算法在磁盘负载较大时比较占优势。它们之间的比较见表4-4。

表4-4  磁盘调度算法比较
  优  点 缺  点
FCFS算法 公平、简单 平均寻道距离大,仅应用在磁盘I/O较少的场合
SSTF算法 性能比“先来先服务”好 不能保证平均寻道时间最短,可能出现“饥饿”现象
SCAN算法 寻道性能较好,可避免“饥饿”现象 不利于远离磁头一端的访问请求
C-SCAN算法 消除了对两端磁道请求的不公平 --

除减少寻找时间外,减少延迟时间也是提高磁盘传输效率的重要因素。可以对盘面扇区进行交替编号,对磁盘片组中的不同盘面错位命名。假设每个盘面有8个扇区,磁盘片组共 8个盘面,则可以釆用如图4-29所示的编号。


图4-29磁盘片组扇区编号

磁盘是连续自转设备,磁头读/写一个物理块后,需要经过短暂的处理时间才能开始读/ 写下一块。假设逻辑记录数据连续存放在磁盘空间中,若在盘面上按扇区交替编号连续存放,则连续读/写多个记录时能减少磁头的延迟时间;同柱面不同盘面的扇区若能错位编号,连续读/写相邻两个盘面的逻辑记录时也能减少磁头延迟时间。

由于传输时间由磁盘转速决定,所以无法通过其他方法减少传输时间。以图4-29为例,在随机扇区访问情况下,定位磁道中的一个扇区平均需要转过4个扇区,这时,延迟时间是传输时间的4倍,这是一种非常低效的存取方式。理想化的情况是不需要定位而直接连续读取扇区,没有延迟时间,这样磁盘数据存取效率可以成倍提高。但是由于读取扇区的顺序是不可预测的,所以延迟时间不可避免。图4-29中的编号方式是读取连续编号扇区时的一种方法。

时间: 2024-10-08 10:49:31

磁道调度的相关文章

磁盘调度-01

磁盘调度,简单的讲就是让磁盘工作,并且符合我们的要求的工作! 很多初学者可能多磁盘调度和文件系统弄混,其实他们是两个完全不相同的概念. 磁盘调度可以说是一个磁盘的驱动系统,由磁盘厂商设计和开发.而文件系统属于操作系统的一部分,它比磁盘调度系统更高一级,他直接面向上层用户. 那就说说磁盘的调度过程吧,上图. 如图,我们知道,文件系统的存取是按簇的读取的,簇的大小一般和内存块的大小一样,或者整数倍.windows簇的概念等价于linux的块的概念.而磁盘的最小读写单位是扇区(当然不是位),显然我们可

磁盘调度-02

上节讲了磁盘的一些基本知识. 这一节我们就开始磁盘的真正调度,调度之前需要先说一个知识点. 磁盘参数: 1. 磁盘容量 = 磁头数 * 柱面数 * 扇区数 * 512bytes,固定的 2. 转速:转速决定读写512字节的速度 3. 平均访问时间:是指磁头从起始位置到到达目标磁道位置,并且从目标磁道上找到要读写的数据扇区所需的时间. 平均访问时间=平均寻道时间+平均等待时间. 4. 传输速率:传输速率分内部传输速率和外部传输速率.内部传输速率由磁盘转速和平均访问时间决定.外部传输速率即系统总线与

python的sched模块--延时调度

我们经常需要定时的执行某个任务,在Linux下我们有强大的crontab,但是在Python这个粒度(定时执行函数),如何处理呢?除了第三方的模块外,标准库为我们提供了sched模块和Timer类. 先说sched模块,准确的说,它是一个调度(延时处理机制),每次想要定时执行某任务都必须写入一个调度.使用步骤如下:(1)生成调度器:s = sched.scheduler(time.time,time.sleep)第一个参数是一个可以返回时间戳的函数,第二个参数可以在定时未到达之前阻塞.可以说sc

Linux进程管理与调度-之-目录导航【转】

转自:http://blog.csdn.net/gatieme/article/details/51456569 版权声明:本文为博主原创文章 && 转载请著名出处 @ http://blog.csdn.net/gatieme 目录(?)[-] 项目链接 进程的描述 进程的创建 进程的加载与运行 进程的退出 进程的调度 调度普通进程-完全公平调度器CFS 日期 内核版本 架构 作者 GitHub CSDN 2016-07-21 Linux-4.6 X86 & arm gatieme

L2-014. 列车调度

火车站的列车调度铁轨的结构如下图所示. Figure 两端分别是一条入口(Entrance)轨道和一条出口(Exit)轨道,它们之间有N条平行的轨道.每趟列车从入口可以选择任意一条轨道进入,最后从出口离开.在图中有9趟列车,在入口处按照{8,4,2,5,3,9,1,6,7}的顺序排队等待进入.如果要求它们必须按序号递减的顺序从出口离开,则至少需要多少条平行铁轨用于调度? 输入格式: 输入第一行给出一个整数N (2 <= N <= 105),下一行给出从1到N的整数序号的一个重排列.数字间以空格

分布式调度QUARTZ+SPRING

使用SPRING的定时任务框架,如果是在分布式的环境下,由于有多台节点,会产生相同的任务,会被多个节点执行,这时需引入分布式的QUARTZ. 触发器:存放时间排程 任务:蔟业务代码 排程器:负责调度,即在指定的时间执行对应的任务 如果是分布式QUARTZ,则各个节点会上报任务,存到数据库中,执行时会从数据库中取出触发器来执行,如果触发器的名称和执行时间相同,则只有一个节点去执行此任务. 如果此节点执行失败,则此任务则会被分派到另一节点执行. quartz.properties # =======

电梯调度——调研报告

需求调研报告 立项背景: 石家庄铁道大学基础教学大楼是一座18层的建筑,其内部配备4部电梯,学生和老师使用电梯的高峰时段相对集中于每次上课/下课的时段,故电梯的使用具有突发性和荷载量大的特点,故设计合理的电梯调度算法,避免出现 “公共汽车”,即把电梯作为总线,它从底部到顶部,停在每一层楼,打开门,让人们进出,然后把门关上,继续前进.之后到达顶层,它会下去.可以极大的提高电梯的工作效率. 石家庄铁道大学基础教学楼的电梯配置如下: 电梯数量:4部 电梯的最大容量为15人 电梯经过每楼层的时间:3秒

结对开发--电梯调度报告

“电梯调度”需求分析 一.项目背景 试想一下,石家庄铁道大学基础教学楼的电梯配置如下:大厦有18层, 4部电梯,很多乘客使用这些电梯的日常(旅客重量:平均70公斤最大120公斤,最小45公斤).其他常量数据:电梯速度,开/关门时间,乘客的时间要在/走出电梯.可以对这些合理的假设. 二.数据分析 我们随机选择了一天去现场调查基础教学楼电梯的使用情况,列表如下: 电梯名称 停靠层数 乘客限制 重量限制/kg 电梯开关时间/s 乘客进出电梯时间/s 电梯1 8-18层(双层) 15人 1150 4s

iOS_31_cocos2d_消息调度

最终效果如图: cocos2d V3 只要实现了- (void)update:(CCTime)delta方法, 就会自动调用它,无需手动调用 foreach   或者说for in遍历的时侯,不能增删成员 封装的 子弹类,继承自CCSprite // // Bullet.h // 31_cocos2D入门 // // Created by beyond on 14-9-7. // Copyright (c) 2014年 com.beyond. All rights reserved. // 子弹