最近在看《linux核心設計與實現》這本書，寫些東西記錄一下學習過程。
塊裝置最突出的特點是可以隨機訪問固定大小的資料片，這些固定大小的資料片稱為塊，塊裝置通過安裝檔案系統來訪問。注意塊裝置都有自己的物理最小定址單元（如扇區），但是在檔案系統下，其有著最小邏輯可定址單元——塊，不要搞混淆了。
與塊裝置相對的是字元裝置，字元裝置按字元流來有序訪問，如串列埠和鍵盤。
像硬碟這樣塊裝置，其定址時間較長，是整個計算中的效能瓶頸。如果任由系統按照i/o請求的順序來進行i/o請求的話其效能難以讓人接受。為此linux核心引入i/o排程程式來管理塊裝置的請求佇列。
通過對i/o請求的合併和排序，有利於減少磁碟定址時間，提高全域性吞吐量，但是合併和排序操作卻導致某些請求長時間得不到相應。下面看下linux中的幾種i/o排程演算法。
1、linus電梯演算法：當乙個請求加入佇列時，有四種可能的情況：1）如果和某個請求相鄰，則合併；2）如果佇列中有乙個請求駐留時間過長，則將其插入到隊尾，防止更嚴重的飢餓；3）如果當前執行的扇區方向有合適的插入位置，則插入；4）如果沒有合適的插入位置，則插到隊尾；
linus電梯演算法存在比較嚴重的飢餓現象：1）對磁碟某一塊的大量讀寫操作會導致磁碟其他位置的請求長時間得不到相應；2）寫操作可以推後到核心有空時執行，但是讀操作的堵塞會直接導致應用程式的堵塞，因此讀請求的優先順序理應高於寫請求。
2、最終期限i/0排程演算法：在與linus電梯排序佇列的基礎上，新增加讀請求fifo佇列和寫請求fifo佇列，預設讀請求超時時間500ms，寫請求超時時間5s。新的請求操作會被同時插入到合併排序佇列和fifo佇列。在fifo佇列沒有請求佇列超時的情況下，對合併佇列進行響應，反之，對fifo佇列進行響應。
3、**i/o排程演算法：**i/o排程演算法是linux核心2.6的預設i/o排程演算法。它在最終期限的i/o排程演算法的基礎上做了如下改進：處理完乙個i/o請求後，並不立即返回處理其他請求，而是會空閒片刻（預設6ms），在此期間新提交的相鄰的i/o請求會立刻得到處理。
**i/o排程演算法在大部分情況下效能理想，但是在某些有嚴格工作負荷的伺服器（如資料庫挖掘伺服器，其執行緒多，每個執行緒的時間片有限，並且各個執行緒的i/o操作不連續）上，這個排程程式執行的效果不好。
4、完全公正的排隊i/o排程演算法：cfq（complete fair queuing）是為專有工作負荷設計的，實際應該中，在幾乎所有的情況下都能很好的執行。cfq將i/o請求按請求所屬的程序來組織，以時間片輪轉排程佇列，從每個佇列中選取請求數（預設4個），然後進行下一輪排程。在程序級提供了公平。
除了以上的四種i/o排程演算法，還有一種稱為：
5、空操作的i/o排程演算法，它的佇列除了合併幾乎不做其他的工作。其適應於真正的隨機訪問裝置，如快閃儲存器卡。
I O排程程式
如果簡單地以核心產生請求的次序直接將請求發向塊裝置的話，效能肯定讓人難以接受。磁碟定址是整個計算機中最慢的操作之一，每一次定址 定位硬碟磁頭到特定塊上的某個位置 需要花費不少時間。所以盡量縮短定址時間無疑是提高系統效能的關鍵。為了優化定址操作，核心既不會簡單的按請求接收次序，也不會立即將其提交給磁碟...
I O排程程式
如果簡單地以核心產生請求的次序直接將請求發向塊裝置的話，效能肯定讓人難以接受。磁碟定址是整個計算機中最慢的操作之一，每一次定址 定位硬碟磁頭到特定塊上的某個位置 需要花費不少時間。所以盡量縮短定址時間無疑是提高系統效能的關鍵。為了優化定址操作，核心既不會簡單的按請求接收次序，也不會立即將其提交給磁碟...
學寫塊裝置驅動（二） 更換IO排程器
上節我們的塊裝置驅動已經可以使用了，本節我們對其進行一點小的改動，修改其使用的io排程器。我們知道，標準磁碟的尋道延時很高，故有了io排程器存在的必要，它通過對io請求進行合併或者排序來提高塊裝置的使用效率。但是因為我們目前的塊裝置在記憶體中，即沒有通常的磁碟尋道延時，且讀寫迅速，所以我們不需要io...