概述

很多时候我们在问题调查中有时候会看到磁盘很忙但是就是不知道谁在写，今天主要介绍几个简单方法能够比较方便的看到磁盘写的细节。

思路

首先，来看看IO协议栈的大致样子，然后我们就知道所谓的查看磁盘读写的工具到底如何工作的了。

从图上可以看到，如果我们要做IO探查工具，首选位置肯定是Block I/O layer这一层，因为所有的IO都流经这里，只要我们能在这里挂个钩子，就可以拦截IO请求。

block_dump

1、block_dump

block_dump的话需要先停掉syslog功能，因为具体IO数据要通过printk输出，如果syslog存在，则会往message产生大量IO，干扰正常结果。

--停止syslog
service syslog stop /systemctl stop syslog
--启动block_dump
echo 1 > /proc/sys/vm/block_dump

设置之后，block层处理的IO请求都会将摘要信息print到缓冲区中，可以通过dmesg查看。比如

$dmesg |grep READ|tail -n 5

每行一个操作，分别表示哪个进程在何时在哪个磁盘（分区）上读写了哪个block，需要注意的是，这里面的block是不是我们说的文件系统的block，是硬件层面的block，可以看做是扇区。每个扇区大小512B，绝大部分的文件系统block都是4K，所以从扇区推算文件系统block只要除以8就可以了，比如60177696的文件系统block是7522212。

2、debugfs

接下来可以使用debugfs来查看该文件的inode以及文件名。

Debugfs exists as a simple way for kernel developers to make information available to user space.

这里用到的debugfs很简单，其余命令可以man。

mount -t debugfs none /sys/kernel/debug
--查看dm-0设备
lvdisplay|awk '/LV Name/{n=$3} /Block device/{d=$3; sub(".*:","dm-",d); print d,n;}'
df -h
debugfs -R 'open /dev/sda1'
debugfs -R 'icheck 7522212' /dev/sda1
debugfs -R 'ncheck 524309' /dev/sda1

blktrace

使用blktrace工具，这个工具包含了通用块层和调度层的信息，可以更精确的得到一个IO请求各个阶段的信息，这个本身有不少值得写的，我们只看最简单的用法。

blktrace is a block layer IO tracing mechanism which provides detailed information about request queue operations up to user space.

Blktrace是标准工具，一般系统都是安装好了的，如果没有安装，可以yum install一下。

sudo blktrace -d /dev/sda1 -o b.log
停一会就可以ctrl-c
blkparse b.log.blktrace.* > b.log.parsed
解析输出文件

一个IO请求可以分为很多阶段，包括设备映射，构造请求，插入队列，调度，执行，完成；这些blktrace都能跟踪，并能给出每个阶段的时间.

systemtap

这个是通用工具，追踪IO只是功能之一，有点杀鸡用牛刀的感觉，不详细介绍。麻烦的地方在于环境准备，如果安装完成，则可以直接使用一个公开的脚本检查IO。该脚本的问题是只检查vfs.read/write接口，该接口工作在通用块层以上，所以部分IO请求，比如缺页swapper加载数据的IO是追踪不到的（我们这次碰到的问题就是swapper导致的），这时候就需要追踪ioblock.end这些更底层的接口信息。

通过以上三种方法我们就能知道是哪些进程在频繁的读写哪些文件，可以帮助定位问题。不过IO是个很复杂的体系，这里只是将调查问题过程中的信息记录下来方便以后使用。

觉得有用的朋友多帮忙转发哦！后面会分享更多devops和DBA方面的内容，感兴趣的朋友可以关注下~