作為系統管理員和 VPS 服務商，經常會碰到服務器或者 VPS 磁盤 IO 繁忙的時候，VPSee 通常都會用一些工具來檢測，其中一個常用的工具就是自己寫的 iotop 腳本，可以很方便看到哪個進程在頻繁 IO. 上周五收到一位網友的郵件和留言，問到這篇文章：如何查看進程 IO 讀寫情況？裡的 WRITE 為什麼會出現是 0 的情況，這是個好問題，VPSee 在這裡好好解釋一下。首先看看我們怎麼樣才能實時監測不同進程的 IO 活動狀況。
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)
{
int count = bio_sectors(bio);
BIO_BUG_ON(!bio->bi_size);
BIO_BUG_ON(!bio->bi_io_vec);
bio->bi_rw |= rw;
if (rw & WRITE)
count_vm_events(PGPGOUT, count);
else
count_vm_events(PGPGIN, count);
if (unlikely(block_dump)) {
char b[BDEVNAME_SIZE];
printk(KERN_DEBUG "%s(%d): %s block %Lu on %s\n",
current->comm, current->pid,
(rw & WRITE) ? "WRITE" : "READ",
(unsigned long long)bio->bi_sector,
bdevname(bio->bi_bdev,b));
}
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 開始。
