block_dump linux 核心裡提供了乙個 block_dump 引數用來把 block 讀寫(write/read)狀況 dump 到日誌裡，這樣可以通過 dmesg 命令來檢視，具體操作步驟是：
# sysctl vm.block_dump=1 or # echo 1 >/proc/sys/vm/block_dump
然後就可以通過 dmesg 就可以觀察到各個程序 io 活動的狀況了：
# dmesg -c
kjournald(542): write block 222528 on dm-0
kjournald(542): write block 222552 on dm-0
bash(18498): dirtied inode 5892488 (ld-linux-x86-64.so.2) on dm-0
bash(18498): dirtied inode 5892482 (ld-2.5.so) on dm-0
dmesg(18498): dirtied inode 11262038 (ld.so.cache) on dm-0
dmesg(18498): dirtied inode 5892496 (libc.so.6) on dm-0
dmesg(18498): dirtied inode 5892489 (libc-2.5.so) on dm-0
問題 一位細心的網友提到這樣乙個問題：為什麼會有 write block 0 的情況出現呢？vpsee 跟蹤了一段時間，發現確實有 write 0 的情況出現，比如：
# dmesg -c ...
pdflush(23123): write block 0 on sdb1
pdflush(23123): write block 16 on sdb1
pdflush(23123): write block 104 on sdb1
pdflush(23123): write block 40884480 on sdb1 ...
答案 原來我們把 write block 0，write block 16, write block 104 這裡面包含的數字理解錯了，這些數字不是代表寫了多少 blocks，是代表寫到哪個 block，為了尋找真相，vpsee 追到 linux 2.6.18 核心**裡，在 ll_rw_blk.c 裡找到了答案：
$ vi linux-2.6.18/block/ll_rw_blk.c
void submit_bio(int rw, struct bio *bio)
generic_make_request(bio);
}
很明顯從上面**可以看出 write block 0 on sdb1，這裡的 0 是 bio->bi_sector，是寫到哪個 sector，不是 write 了多少 blocks 的意思。還有，如果 block 裝置被分成多個區的話，這個 bi_sector(sector number)是從這個分割槽開始計數，比如 block 0 on sdb1 就是 sdb1 分割槽上的第0個 sector 開始。
Linux程序實時IO監控iotop命令詳解
linux下的io統計工具如iostat,nmon等大多數是只能統計到per裝置的讀寫情況,如果你想知道每個程序是如何使用io的就比較麻煩.iotop 是乙個用來監視磁碟 i o 使用狀況的 top 類工具。iotop 具有與 top 相似的 ui，其中包括 pid 使用者 i o 程序等相關資訊。...
Linux shell 實時監測程序 top命令
前言 當程式執行在系統時，我們稱子為程序。想要監測這些程序，需要用到ps命令。雖然ps命令在收集執行在系統中的資訊時非常有用。但是不足之處在於，ps命令只能顯示某個特定時間點的資訊。而要想實時監測程序狀態，需要用到接下來所講的top命令。實時監測程序 我們前言也說了，ps命令只能顯示某個特定時間點的...
python監測linux程序
很多時候我們都需要監測linux伺服器中的乙個或多個程序是否正常執行，並能通過郵件的方式通知系統管理員。使用python編寫乙個監測程序是否執行正常的指令碼是很方面和高效的，那麼我們就使用python中的subprocess模組並結合linux命令來簡單實現乙個監測指令碼。subprocess的主要...