debugfs和blktrace的实验

本文介绍了如何使用debugfs和blktrace工具进行磁盘IO分析,通过实验发现debugfs操作耗时且可能导致高磁盘读取。在实际诊断hot file disk IO时,需要对blkparse结果进行处理,聚合相同设备的扇区信息。同时,遇到ext4文件系统journaled模式下debugfs显示问题,始终关注同一inode。
摘要由CSDN通过智能技术生成

看了通过blktrace, debugfs分析磁盘IO大作,试图自己搞一把。花了1个多小时,果然能成功地定位到了正写入的文件。觉得有以下几点值得特别说一下:


1、用debugfs,无论icheck或ncheck,都非常耗时,并且会产生非常高的disk read。我等了将近有10分钟

rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util 

cciss/c0d1 21880.00 0.00 432.00 0.00 178752.00 0.00 413.78 0.95 2.21 2.18 94.20 
cciss/c0d1p1 21880.00 0.00 432.00 0.00 178752.00 0.00 413.78 0.95 2.21 2.18 94.20

2、真的实际要对hot file disk IO进行诊断,其实需要对blkparse的结果进行处理,需要对相同设备的相同、临近扇区号进行聚合(假设顺序读写)

3、arrowpig同学发现,对于ext4在journey开时做debugfs还有些问题,主要是ext4总是先写journey的一个缓存区,导致debugfs总是看到同一inode号(inode=8)。不知这个应该如何解决?


[op1@SVR2084HP360 ~]$  sudo  blktrace /dev/cciss/c0d1p1

BLKTRACESTOP: Invalid argument
Device: /dev/cciss/c0d1p1
  CPU  0:              
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值