作为系统管理员和 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 %sn“,
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 开始。
