很多情况下开发者调测程序需要在Linux下获取具体的IO的状况&＃xff0c;目前常用的IO观察工具用vmstat和iostat&＃xff0c;具体功能上说当然是iostat更胜一筹&＃xff0c;在IO统计上时间点上更具体精细。但二者都是在全局上看到IO&＃xff0c;宏观上的数据对于判断IO到哪个文件上毫无帮助&＃xff0c;这个时候block_dump的作用就显现出来了。
一、使用方法&＃xff1a;
需要先停掉syslog功能&＃xff0c;因为具体IO数据要通过printk输出&＃xff0c;如果syslog存在&＃xff0c;则会往message产生大量IO&＃xff0c;干扰正常结果
| 1 2 | suse:~ # service syslog stop Shutting down syslog services done |
然后启动block_dump
| 1 | suse:~ # echo 1 > /proc/sys/vm/block_dump |
先说效果&＃xff1a;
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | suse:~ # dmesg | tail dmesg(3414): dirtied inode 9594 (LC_MONETARY) on sda1 dmesg(3414): dirtied inode 9238 (LC_COLLATE) on sda1 dmesg(3414): dirtied inode 9241 (LC_TIME) on sda1 dmesg(3414): dirtied inode 9606 (LC_NUMERIC) on sda1 dmesg(3414): dirtied inode 9350 (LC_CTYPE) on sda1 kjournald(506): WRITE block 3683672 on sda1 kjournald(506): WRITE block 3683680 on sda1 kjournald(506): WRITE block 3683688 on sda1 kjournald(506): WRITE block 3683696 on sda1 kjournald(506): WRITE block 3683704 on sda1 kjournald(506): WRITE block 3683712 on sda1 kjournald(506): WRITE block 3683720 on sda1 kjournald(506): WRITE block 3683728 on sda1 kjournald(506): WRITE block 3683736 on sda1 kjournald(506): WRITE block 3683744 on sda1 |
通过dmesg信息可以看到IO正在写那些文件&＃xff0c;有进程号&＃xff0c;inode号&＃xff0c;文件名和磁盘设备名&＃xff1b;但每个文件写了多少呢&＃xff0c;仅仅通过dirtied inode就看不出来了&＃xff0c;还需要分析WRITE block&＃xff0c;后面的数字并不是真正的块号&＃xff0c;而是内核IO层获取的扇区号&＃xff0c;除以8即为块号&＃xff0c;然后根据debugfs工具的icheck和ncheck选项&＃xff0c;就可以获取该文件系统块属于哪个具体文件&＃xff0c;具体请google之。
二、基本原理&＃xff1a;
block_dump的原理其实很简单&＃xff0c;内核在IO层根据标志block_dump在IO提交给磁盘的关口卡主过关的每一个BIO&＃xff0c;将它们的数据打出来&＃xff1a;
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 | void submit_bio(int rw, struct bio *bio) { int count &＃61; bio_sectors(bio); bio->bi_rw |&＃61; rw; /* * If it&＃39;s a regular read/write or a barrier with data attached, * go through the normal accounting stuff before submission. */ if (bio_has_data(bio) && !(rw & REQ_DISCARD)) { if (rw & WRITE) { count_vm_events(PGPGOUT, count); } else { task_io_account_read(bio->bi_size); count_vm_events(PGPGIN, count); } if (unlikely(block_dump)) { char b[BDEVNAME_SIZE]; printk(KERN_DEBUG "%s(%d): %s block %Lu on %s (%u sectors)n", current->comm, task_pid_nr(current), (rw & WRITE) ? "WRITE" : "READ", (unsigned long long)bio->bi_sector, bdevname(bio->bi_bdev, b), count); } } generic_make_request(bio); } |
具体WRITE block块号和文件系统块号之间的对应关系在submit_bh函数中决定
| 1 | bio->bi_sector &＃61; bh->b_blocknr * (bh->b_size >> 9); |
这段代码输入形如&＃xff1a;
| 1
| [10489963.254731] kworker/u65:0(119773): WRITE block 3017556368 on sdm (136 sectors)
|
[10489963.254731] kworker/u65:0是current->comm&＃xff0c;即struct task_struct的comm字段&＃xff0c;注释上说”executable name excluding path”&＃xff1b;
119773是task_pid_nr(current)&＃xff0c;即线程id&＃xff1b;
WRITE表明当前block io是写操作&＃xff1b;
3017556368是bio->bi_iter.bi_sector&＃xff0c;这个值是struct bio的struct bvec_iter bi_iter中的bi_sector&＃xff0c;表示当前block io的第一个sector号&＃xff1b;
sdm是bdevname(bio->bi_bdev, b)&＃xff0c;设备名&＃xff1b;
136是count&＃xff0c;当前block io的sector数&＃xff1b;
inode的block_dump实现是通过block_dump___mark_inode_dirty搞定的&＃xff0c;这次把关口架在inode脏数据写回的路上&＃xff0c;把每个过关的inode信息打出来&＃xff1a;
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 | void __mark_inode_dirty(struct inode *inode, int flags) { if (unlikely(block_dump)) block_dump___mark_inode_dirty(inode); } static noinline void block_dump___mark_inode_dirty(struct inode *inode) { if (inode->i_ino || strcmp(inode->i_sb->s_id, "bdev")) { struct dentry *dentry; const char *name &＃61; "?"; dentry &＃61; d_find_alias(inode); if (dentry) { spin_lock(&dentry->d_lock); name &＃61; (const char *) dentry->d_name.name; } printk(KERN_DEBUG "%s(%d): dirtied inode %lu (%s) on %sn", current->comm, task_pid_nr(current), inode->i_ino, name, inode->i_sb->s_id); if (dentry) { spin_unlock(&dentry->d_lock); dput(dentry); } } } |
三、总结
1.内核由很多合适的关口来截获获取的IO信息&＃xff0c;不改动内核&＃xff0c;也可以用jprobe抢劫很多东西。
2.debugfs在大量的block-->file转换过程总太慢&＃xff0c;自己用ext2fs写一个&＃xff0c;效率应该能提高很多。
block_dump观察Linux IO写入的具体文件来自于OenHan
京公网安备 11010802041100号