【許久之前就用過blktrace，現整理如下】
從linux 乙個完整的io入手分析：
乙個i/o請求進入block layer之後，可能會經歷下面的過程：
split: 可能會因為i/o請求與扇區邊界未對齊、或者size太大而被分拆(split)成多個物理i/o
merge: 可能會因為與其它i/o請求的物理位置相鄰而合併(merge)成乙個i/o
被io scheduler依照排程策略傳送給driver
被driver提交給硬體，經過hba、電纜（光纖、網線等）、交換機（san或網路）、最後到達儲存裝置，裝置完成io請求之後再把結果發回。
blktrace 能夠記錄下io所經歷的各個步驟:
一起看下blktrace的輸出長什麼樣子：
其中第六個字段非常有用：每乙個字母都代表了io請求所經歷的某個階段。
1注意，我們心心念念的service time，也就是反應塊裝置處理能力的指標，就是從d到c所花費的時間，簡稱d2c。q – 即將生成io請求
2 |3
g – io請求生成
4 |5
i – io請求進入io scheduler佇列
6 |7
d – io請求進入driver
8 |9 c – io請求執行完畢
而iostat輸出中的await，即整個io從生成請求到io請求執行完畢，即從q到c所花費的時間，我們簡稱q2c。
我們知道linux 有i/o scheduler，排程器的效率如何，i2d是重要的指標。
注意，這只是blktrace輸出的乙個部分，很明顯，我們還能拿到offset和size，根據offset，我們能拿到某一段時間裡，應用程式都訪問了整個塊裝置的那些block，從而繪製出塊裝置訪問軌跡圖。
另外還有size和第七個字段（read or write），我們可以知道io size的分布直方圖。對於本文來講，我們就是要根據blktrace來獲取這些資訊。
多路I O復用分析
今天看到乙個i o效能的問題。就對這個問題思考了下。linux下幾種常見的i o分析在本部落格此處 分析阻塞 非阻塞i o，這兩種i o乙個共同點是，很多i o中無法確認那些i o是準備好，只能通過乙個個輪詢的方式，這種方式下，準備好與沒有準備好的i o均會被輪詢，這種效率極其低下。非同步i o，提...
io對比分析
1 同步阻塞io 使用者執行緒通過系統呼叫read發起io讀操作，由使用者空間轉到核心空間。核心等到資料報到達後，然後將接收的資料拷貝到使用者空間，完成read操作。使用者執行緒使用同步阻塞io模型的偽 描述為 2同步非阻塞io 使用者執行緒系統系統呼叫read 後直接返回，然後通過不斷輪訓的方式，...
linux 磁碟io分析 整理
1.dd命令 基本的測試磁碟io的命令 dd if dev sda of test.flie bs 1m count 512 conv fdatasync if 讀取檔案位置 of 寫入檔案 bs 讀寫位元組單位 count 塊數 conv fdatasync 保證讀寫到磁碟，而不是記憶體中。ech...