我正在运行一个Web服务器（Ubuntu 11.04），显示意外的高写入stream量。 当服务器根本不应该写入时，写入通信量与读取通信量相当。
关心不必要的写操作，我试图分析系统出了什么问题。 我可以排除沉重的Apache日志或访问时间问题（使用noatime挂载configuration）。
为了追踪这个问题，我想查看哪些文件写在哪里。 因此，我通过block_dump（关于此主题的有用博客条目： sprocket.io ）启用了IOlogin。 每个文件系统活动都将logging在syslog中。 这里是我的系统的一个简短的摘录：
8月21日18:22:55 xxxxx内核：[3984721.590864] apache2（2761）：读块1098502400 md2（8个扇区）
8月21日18:22:55 xxxxx内核：[3984721.594005] kjournald（316）：在md2上的WRITE块2224394648（8个扇区）
8月21日18:22:55 xxxxx内核：[3984721.594029] md2_raid1（260）：在sdb3上写入块2925532672（8个扇区）
8月21日18:22:55 xxxxx内核：[3984721.594044] md2_raid1（260）：WRITE块2925532672 sda3（8个扇区）
8月21日18:22:55 xxxxx内核：[3984721.644244] apache2（2761）：读取md2上的块2242118744（8个扇区）
好吧，现在我知道写了什么块。 但有没有一种方法来真正识别基于这些块ID的文件名？
谢谢你的帮助！
顺便说一句：我使用的软件RAID，可能是问题的一部分。
假设ext2 / ext3 / ext4，开始
[406420.877412] vi(12496): READ block 4522288 on dm-1 (8 sectors) 确定文件系统块大小：
# /sbin/dumpe2fs /dev/dm-1 | grep 'Block size' dumpe2fs 1.42.3 (14-May-2012) Block size: 4096
假设你有一个有512字节扇区的驱动器，把块分割成4096/512，也就是8，得到565286。
在debugfs使用icheck和ncheck的组合：
debugfs: icheck 565286 Block Inode number 565286 142506 debugfs: ncheck 142506 Inode Pathname 142506 /etc/security/time.conf
编辑：在md *设备上执行此操作，而不是在sd *设备上执行此操作。 sd *设备I / O是软件raid的结果。
文件系统驻留在比块设备和软件RAID更高的抽象层次上。 也就是说，软件RAID不是99.9％概率的问题的一部分，它只是一个块设备。 所以，你应该使用其他工具来分析你的I / O活动。 我会build议从iotop开始，首先确定正在运行的进程中的顶级作家。 然后，您将能够使用lsof和strace来识别正在写入的文件。
Linux有一个名为inotify的内核系统来监视文件的任何变化。 在userland中，可以使用inotify-tools （ apt-get install inotify-tools ）来查看一个目录。 但是，每个文件都必须放置一个单独的手表。 你可以recursion地将它们应用到一个目录（甚至是根目录），但是你看的越less，开销就越less。
缩小范围的其他选项包括：
atop此atop将允许您查看哪些进程正在执行写入 auditctl ，它有一个非常神秘的语法，但允许手表放在任何系统调用