惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

博客园_首页
I
InfoQ
The Register - Security
The Register - Security
L
LangChain Blog
H
Help Net Security
The GitHub Blog
The GitHub Blog
S
Schneier on Security
博客园 - 【当耐特】
W
WeLiveSecurity
Attack and Defense Labs
Attack and Defense Labs
IT之家
IT之家
CTFtime.org: upcoming CTF events
CTFtime.org: upcoming CTF events
Google DeepMind News
Google DeepMind News
The Cloudflare Blog
H
Heimdal Security Blog
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
Y
Y Combinator Blog
雷峰网
雷峰网
N
Netflix TechBlog - Medium
Security Archives - TechRepublic
Security Archives - TechRepublic
cs.AI updates on arXiv.org
cs.AI updates on arXiv.org
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
L
Lohrmann on Cybersecurity
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
T
The Exploit Database - CXSecurity.com
P
Privacy & Cybersecurity Law Blog
G
GRAHAM CLULEY
Exploit-DB.com RSS Feed
Exploit-DB.com RSS Feed
V
Visual Studio Blog
博客园 - 聂微东
PCI Perspectives
PCI Perspectives
Last Week in AI
Last Week in AI
A
Arctic Wolf
宝玉的分享
宝玉的分享
T
The Blog of Author Tim Ferriss
S
Secure Thoughts
T
Threat Research - Cisco Blogs
GbyAI
GbyAI
云风的 BLOG
云风的 BLOG
D
Darknet – Hacking Tools, Hacker News & Cyber Security
S
SegmentFault 最新的问题
SecWiki News
SecWiki News
月光博客
月光博客
大猫的无限游戏
大猫的无限游戏
Schneier on Security
Schneier on Security
P
Proofpoint News Feed
博客园 - Franky
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
AI
AI
Engineering at Meta
Engineering at Meta

蛮荆

如何获取更多的免费服务器 Kubernetes 调度器队列 - 设计与实现 Kubernetes 调度器 - 核心流程 Kubernetes Networking Model & CNI Kubernetes 控制器管理总结 Kubernetes CronJob 设计与实现 Kubernetes Job 设计与实现 Kubernetes HPA 设计与实现 Kubernetes Deployment 滚动更新实现原理 Kubernetes GC 设计与实现 Kubernetes Pod 驱逐 - 设计与实现 Kubernetes Daemonset 设计与实现 Kubernetes ReplicaSet 设计与实现 Kubernetes EndPoint 设计与实现 Kubernetes Informer 设计与实现 降本增效之应用优化 (三) 日志存储与检索 Kubernetes Pod 设计与实现 - 创建流程 Kubernetes 探针设计与实现 Unix 编程艺术名句摘录 Kubernetes - CRI 概述 Golang 编译速度为什么这么快? Kubernetes Pod 设计与实现 - Pause 容器 Kubernetes - kube-proxy 代理模式工程优化 Kubernetes 应用最佳实践 - 优雅关闭长连接 Kubernetes Service 类型和会话亲和性 Kubernetes 为什么需要 Ingress Kubernetes 架构 - 控制平面和数据平面 降本增效之应用优化 (二) 大报表 Go 语言如何获取 CPU 利用率 降本增效之应用优化 (一) Redis 业务规则引擎演变过程简述 微服务中的熔断算法 漏桶算法和令牌桶算法 jsonparser 为什么比标准库的 encoding/json 快 10 倍 ? zap 高性能设计与实现 HTTP Router 算法演进 fastcache 高性能设计与实现 Web 常见的三个安全问题 ants Code Reading Go 线程安全 map 方案选型 布隆过滤器 死锁、活锁、饥饿、自旋锁 sync.Pool Code Reading Go 内存管理概述 Go netpoll Code Reading goroutine 泄漏与检测 time/Timer Code Reading GMP Scheduler Code Reading Go channel 的 15 条规则和底层实现 为什么 Linux “一切皆文件” context.Context Code Reading runtime/HACKING.md Goland 最佳实践 互联网开发与金庸武学 为什么 Redis 6.0 引入多线程模型? Kubernetes 应用最佳实践 - 金丝雀发布 容器中如何正确配置 GOMAXPROCS ? singleflight Code Reading sync.Map Code Reading sync.Cond Code Reading sync.WaitGroup Code Reading sync.RWMutex Code Reading sync.Mutex Code Reading sync.Once Code Reading Go 无锁编程 sync/atomic Code Reading goroutine 交替打印奇偶数 GODEBUG Go 并发模式 Go 汇编 UUID 通用技术选型 Kubernetes 应用最佳实践 - 水平自动伸缩 Go 高性能 Tips fasthttp 为什么比标准库 net/http 快 10 倍 ? 技术文章配图指南 ChatGPT 初体验 Docker 网络原理概览 iptables 的五表五链 Kubernetes 应用最佳实践 - 亲和性和污点容忍度 Go 的反射与三大定律 Docker 官方提供的最佳实践 Go 语言内置的设计模式 HTTP1 到 HTTP3 的工程优化 Kubernetes 应用最佳实践 - Sidecar 模式 Kubernetes 应用最佳实践 - init 容器和钩子函数 为什么 recover 必须在 defer 中调用? 为什么 defer 的执行顺序和注册顺序不同? Go map 设计与实现 Go 切片扩容底层实现 Go 语言中的零拷贝 Go Delve 云原生和边缘计算简介 Kubernetes Pod 服务质量等级 Kubernetes 应用最佳实践 - 探针 Kubernetes 应用最佳实践 - 资源请求和限制 CDN 原理 Kubernetes 应用最佳实践 - 开篇 缓存策略和模式 Go 内存模型 Kubernetes 核心概念
磁盘结构和调度算法
2018-03-09 · via 蛮荆

磁盘结构和调度算法

2018-03-09 操作系统

  • 磁盘结构
  • 磁盘调度算法
    • 1. 先来先服务 (FCFS, First Come First Served)
    • 2. 最短寻道时间优先 (SSTF, Shortest Seek Time First)
    • 3. 电梯算法
      • 循环电梯算法
      • LOOK 与 C-LOOK算法

磁盘结构

上面的图片展示了一个常见的机械磁盘。

  • 盘面(Platter):一个磁盘有多个盘面;
  • 磁道(Track):盘面上的圆形带状区域,一个盘面可以有多个磁道;
  • 扇区(Track Sector):磁道上的一个弧段,一个磁道可以有多个扇区,它是最小的物理储存单位;
  • 磁头(Head):与盘面非常接近,能够将盘面上的磁场转换为电信号(读),或者将电信号转换为盘面的磁场(写);
  • 柱面(Cylinder):多个具有相同编号的磁道形成一个圆柱,称为磁盘的柱面;
  • 制动手臂(Actuator arm):用于在磁道之间移动磁头;
  • 主轴(Spindle):使整个盘面转动;

下面在来一张三维图片,可以更直观地展示出不同的盘面。

读写一个磁盘块的时间的影响因素有:

  • 旋转时间(主轴转动盘面,使得磁头移动到目标扇区上)
  • 寻道时间(制动手臂移动,使得磁头移动到目标磁道上)
  • 实际的数据传输时间

其中寻道时间最长,因此 磁盘调度算法的主要目标是使磁盘的平均寻道时间最短,也就是优化磁盘的访问请求顺序。

磁盘调度算法

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

按照磁盘请求的顺序进行调度,也就是朴素的排队算法。

优点: 实现简单、相对公平 缺点: 未对寻道做任何优化,使平均寻道时间可能较长

  • 假设现在有一个磁道请求队列: 98,183,37,122,14,124,65,67
  • 假设当前磁头位于 53 号磁道

采用 FCFS 算法,磁道移动距离等于:

(98-53) + (183-98) + (183-37) + (122-37) + (122-14) + (124-14) + (124-65) + (67-65) = 640

如果系统中存在大量进程竞争使用磁盘,请求访问的磁道可能非常分散,FCFS 算法因为寻道时间过长,在性能上会表现很差。

2. 最短寻道时间优先 (SSTF, Shortest Seek Time First)

优先调度与当前磁头所在磁道距离最近的磁道,虽然平均寻道时间比较低,但是不够公平。

如果新到达的磁道请求总是比一个在等待的磁道请求近,那么在等待的磁道请求会一直等待下去,也就是出现饥饿现象。如果请求磁道正好位于对立的两端,更容易出现饥饿现象。

  • 假设现在有一个磁道请求队列: 98,183,37,122,14,124,65,67
  • 假设当前磁头位于 53 号磁道

采用 SSTF 算法,磁道移动距离等于:

(65-53) + (67-65) + (67-37) + (37-14) + (98-14) + (122-98) + (124-122) + (183-124) = 236

SSTF 算法相比 FCFS 算法,性能提高了很多,但可能存在某些磁道请求的饥饿现象。

  • 假设现在有一个磁道请求队列: 53,183 … 后面所有请求磁道号均小于 53
  • 假设当前磁头位于 53 号磁道

那么 183 号磁道可能永远不会被响应,于是产生了饥饿现象,磁头只在 0 - 53 号这个区域内来回移动。

3. 电梯算法

SSTF 算法会产生饥饿的原因在于:磁头有可能在一个小区域内来回移动。

电梯算法可以防止这个问题,电梯算法规定:磁头只能在一个方向上移动,访问所有未完成的请求,直到磁头到达该方向上的最后的磁道,然后改变方向

就像现实中的电梯一样,总是按一个方向来进行磁盘调度,直到该方向上没有未完成的磁盘请求,然后改变方向。

  • 假设现在有一个磁道请求队列: 98,183,37,122,14,124,65,67
  • 假设当前磁头位于 53 号磁道

磁头先响应左边的请求,直到到达最左端( 0 磁道)后,才开始反向移动,响应右边的请求。

采用电梯算法,磁道移动顺序:

37,14,0,65,67,98,122,124,183

磁道移动距离等于:

(53-37) + (37-14) + (14-0) + (65-0) + (67-65) + (98-67) + (122-98) + (124-122) + (183-124) = 236

电梯算法性能较好,而且不会产生饥饿问题,但是位于中间部分的磁道比较 “占便宜”,因为中间部分相比其他部分的响应频率会较多,结果就是每个磁道的响应频率是不一样的。就像现实中坐电梯一样,不论电梯是上还是下,中间楼层的乘客可以直接乘坐电梯的概率更大。

循环电梯算法

电梯算法使得每个磁道的响应频率存在差异,要优化这个问题,可以总是保持相同的方向进行扫描,使得每个磁道的响应频率基本一致。

循环电梯扫描 规定:只有磁头朝某个特定方向移动时,才处理磁道访问请求,而返回时直接移动到对端边缘的磁道,也就是复位磁头,这个过程是很快的,并且返回中途不处理任何请求,该算法的特点就是 磁道只响应当前同一个方向上的请求

  • 假设现在有一个磁道请求队列: 98,183,37,122,14,124,65,67
  • 假设当前磁头位于 53 号磁道

假设循环电梯调度算先朝磁道增加的方向移动,磁道移动顺序:

65,67,98,122,124,183,199,0,14,37

磁道移动距离等于 (忽略磁头复位):

(65-53) + (67-65) + (98-67) + (122-98) + (124-122) + (183-124) + (199-183) + (14-0) + (37-14) = 183

磁头先响应了右边的请求,直到碰到了最右端的磁道 199,就立即回到磁盘的开始处(磁道 0),但这个返回的途中是不响应任何请求的,直到到达最开始的磁道后,才继续顺序响应右边的请求。

循环电梯算法相比于电梯算法,对于各个位置磁道响应频率相对比较平均。

LOOK 与 C-LOOK算法

刚才提到的电梯算法和循环电梯算法,都是磁头移动到磁盘「最始端或最末端」之后,然后再开始调换方向。这部分其实是可以优化的,优化的思路就是 磁头在移动到「最远的请求」位置,然后立即反向移动即可。

针对电梯算法的优化则叫 LOOK 算法,磁头在每个方向上仅仅移动到最远的请求位置,然后立即反向移动,而不需要移动到磁盘的最始端或最末端,反向移动的途中会响应请求

LOOK 算法

针对循环电梯算法的优化叫 C-LOOK 算法,磁头在每个方向上仅仅移动到最远的请求位置,然后立即反向移动,而不需要移动到磁盘的最始端或最末端,反向移动的途中不会响应请求

C-LOOK 算法