磁碟排程(disk scheduling)
想像一棟繁忙大樓裡的電梯。許多樓層的人都按了按鈕,一台愚蠢的電梯可能為了一個人衝上十樓,再為了另一個人退回二樓,接著又上九樓——把自己累壞在上上下下之間。明智的電梯則會朝一個方向掃過去,沿途在每個被請求的樓層停下,再掃回來。磁碟排程正是把這個構想套用在硬碟的讀寫臂上:當有好幾個請求在等待時,作業系統該以什麼順序服務它們,才能把臂的來回移動降到最低?
具體來說,在硬碟上,一次存取的主要成本是搜尋(移動臂)加上旋轉延遲。當許多 I/O 請求堆在佇列裡、各自指名不同的磁軌時,你服務它們的順序便決定了臂總共要移動多遠。磁碟排程器會重新排序待處理的佇列,以縮小那段總移動量。最簡單的策略 FCFS(先到先服務)只照請求順序處理——公平但浪費,因為它讓臂到處亂竄。SSTF(最短搜尋時間優先)總是挑最近的待處理磁軌,這能減少移動,卻可能餓死遠處的請求。SCAN 與 C-SCAN 像電梯一樣讓臂穩定地掃過磁碟,而 LOOK 與 C-LOOK 做的事相同,但只走到最外側的待處理請求為止,而非走到磁碟的實體邊緣。
為什麼重要:在硬碟上,良好的排程能讓有效產出率倍增,因為機械移動相較於真正讀取位元實在太慢了。但這裡有個關鍵的現代但書:在 SSD 上沒有臂也沒有搜尋時間,所以按磁軌位置重新排序幾乎買不到任何好處——隨機存取本來就已經幾乎和循序一樣快。SSD 確實能從不同的排程中獲益(例如公平性、批次處理,或不讓讀取被大量寫入卡在後面),但經典的最小化搜尋演算法是為旋轉磁碟而生的,當磁碟退場時它們也大致一同退役。
臂位於第 53 軌,佇列中有對第 98、183、37、122、14、124、65、67 軌的請求。FCFS 照這個順序服務,來回曲折地走了很長的總距離。SCAN 則向上掃(65、67、98、122、124、183)再往下掃回(37、14),順路碰過每一軌,臂的總移動量少得多。
重新排序的是佇列,而非請求本身——這就是全部的訣竅。
磁碟排程在旋轉硬碟上幫助很大,在 SSD 上幫助極小。一個常見的錯誤是把硬碟時代的調校套用到快閃硬碟上;那裡的瓶頸是先抹後寫與磨損,而不是臂的移動。