I/O scheduler的作用就是為請求隊列裡面的IO請求做一個優化，以此達到提高系統吞吐量、縮短響應時間的目的。更改I/O scheduler有兩種方式：
1./sys/block/device_name/queue/scheduler (IOscheduler); /sys/block/device_name/queue/nr_request(queuesize)
2.永久修改？啟動時，grup->edit->elevator =scheduler_name
但是提高系統吞吐量和縮短響應時間是一件矛盾的事情。因為如果為了提高系統吞吐量，則必然要對IO請求的某些順序做改變，這就導致了某些IO請求的響應時間增大。而如果為了減小響應時間（那麼就是來一個請求響應一個）那麼系統吞吐量或許就會降低了。因此linux有了四種I/O scheduler來滿足不同的情況。
1.CFQ(completely fair queuing)
完全公平隊列，實現了請求合並、電梯算法。每個進程的IO請求產生一個隊列，這個隊列是對尋道地址進行排序，盡量減少尋道時間。每個進程的隊列有自己的優先級，然後以時間片輪轉的方式去服務每個進程的請求隊列。[1]
2.Deadline
這種調度方式實現了請求合並、電梯算法，然後為每個請求分配一個超期時間，這樣就避免了某個請求被餓死的情況。在它的實現中分配了好幾個隊列，deadline queue（這個是根據超期時間來排序的），這個是按照磁道訪問順序來的；write queue；read queue。其中read queue的優先級比write queue的優先級高，這主要是因為用戶發出了讀請求後會立馬等待結果，而用戶發出了寫請求後則不會等待他是否完成了（因為用戶看不到）。這三者的優先級關系是Q(read) > Q(read) > Q(deadline)。大概的響應流程：決定下一次是從隊列中響應哪個請求時，首先是從Q(deadline)去查看第一個請求是否超期了，如果沒有那麼就會從read或write隊列（這個應該是根據他們之間的優先級來定的）裡面讀取一批的請求去響應（默認好像是5個）。
3.NOOP
NOOP的全稱是no operations，它就是一個簡單的FIFO，不過它實現了合並請求的功能，也就是說如果兩個請求訪問的額磁道地址在一起，那麼就會合並它們。這種適用於沒有尋到時間的情況，比如說SSD、fusion IO，而不適應HDD。
4.AS
AS其實和CFQ差不蠻多，稱作預期的調度，別的IO scheduler都只是對離散IO做了優化但是並沒有對連續IO作優化，比如說一個IO請求剛執行完的這瞬間又在此位置來了一個IO請求，那麼在AS這種情況下就可以馬上響應剛才新來的那個請求，它是通過每次完成之後等那麼極短的時間來響應的（6ms？）不過現在已經被CFQ取代。www.linuxidc.com 簡單的說：CFQ是一種通用方案，deadline適用database情景，而NOOP適用SSD、fusion IO。但是具體的也要看實際情況，比如說deadline只有在極大地IO情況下才有可能提升一定的性能（自己做過測試，規模比較小，沒有多大性能提升）
下面在談談queue size
Queue size就是用來存在IO請求的隊列的大小，所以理論上來說queue size越大，提升的性能更大，因為有更多的請求被優化了。但是這裡需要注意幾種情況。
1. 在SSD、Fusion IO這種不需要尋道時間（seek time）的情景下，增大了size並沒有多大益處，或許會因為對隊列的維護而帶來負面影響。所以使用之前最好還是測試一下比較合適。
2. 在使用innodb的時候，無論是CFQ還是deadline，都不要設置為太大的queue size。有人說innodb內部也對io請求做了根os一樣的優化（實際上應該指的就是insert buffer），那麼如果在os層把queue size設得太大的話會與innodb內部重復，導致額外的代價，性能或許會更低。
3. Linux的文檔中說deadline比CFQ更適合數據庫這種情況，但是貌似只有在極大地系統壓力情況下deadline才會比CFQ有比較大的性能優勢。
