用systemtap分析磁盘写入操作

前端之家收集整理的这篇文章主要介绍了用systemtap分析磁盘写入操作前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

用systemtap分析磁盘写入操作

转载时请注明出处和作者联系方式
作者联系方式:李先静 <xianjimli at hotmail dot com>


这几天发现有好几块broncho开发板的FLASH坏了,broncho使用的SLC,现在的SLC写入寿命至少在10W次以上,尽管现在的测试要比正常使用高得多,也没有可能在不到一个月就坏了啊。不过最近听人说jffs2的磨损均衡只是在剩余空间中进行,而broncho的剩余空间并不多,这让我觉得事态有些严重。

得做点什么才行。我先想到的是文件操作可能存在问题,没有多少地方需要进行写入操作啊,即使均衡不好,flash也不应该坏得这么快啊。为了揭开这个谜底,我写了个简单的systemtap脚本,用来分析文件写入操作。

  1. probekernel.function("do_sync_write")
  2. {
  3. name="do_sync_write";
  4. dev=__file_dev($filp)
  5. devname=__find_bdevname(dev,__file_bdev($filp))
  6. ino=__file_ino($filp)
  7. filename=__file_filename($filp);
  8. if((uid()==0||uid()==503)&&!isinstr(filename,"[")&&filename!="stap.log")
  9. {
  10. printf("name=%spid=%duid=%dino=%dname=%sfilename=%s/n",name,pid(),uid(),ino,devname,filename);
  11. }
  12. }


输出结果让我有些意外:

  1. name=do_sync_writepid=22542uid=0ino=324338name=sda1filename=sqlite_lVkvYHYHUTVO2SS-journal
  2. name=do_sync_writepid=22542uid=0ino=324338name=sda1filename=sqlite_lVkvYHYHUTVO2SS-journal
  3. name=do_sync_writepid=22542uid=0ino=324338name=sda1filename=sqlite_lVkvYHYHUTVO2SS-journal
  4. name=do_sync_writepid=22542uid=0ino=324338name=sda1filename=sqlite_lVkvYHYHUTVO2SS-journal
  5. name=do_sync_writepid=22542uid=0ino=324338name=sda1filename=sqlite_lVkvYHYHUTVO2SS-journal
  6. name=do_sync_writepid=22542uid=0ino=324316name=sda1filename=sqlite_lVkvYHYHUTVO2SS
  7. name=do_sync_writepid=22542uid=0ino=324316name=sda1filename=sqlite_lVkvYHYHUTVO2SS
  8. name=do_sync_writepid=22542uid=0ino=324316name=sda1filename=sqlite_lVkvYHYHUTVO2SS
  9. name=do_sync_writepid=22542uid=0ino=324316name=sda1filename=sqlite_lVkvYHYHUTVO2SS
  10. name=do_sync_writepid=22542uid=0ino=324316name=sda1filename=sqlite_lVkvYHYHUTVO2SS
居然是sqlite做了大量的临时文件写入操作,仅仅是起动一次就做了800多次写入操作。增加一条记录要写入24次,其中临时文件写入占21次。如果使用的临时文件系统,那没事儿,因为临时文件系统是用内存来模拟的,写多少次都不怕,默认的临时文件系统mount在/tmp下。而我在检查sqlite进程打开的文件时,发现临时文件放在/var/tmp下,问题就出在这里,这不是临时文件系统。我修改sqlite的代码,对flash的写入操作降为原来的1/8。希望这个改动确实有效。~~end~~

猜你在找的Sqlite相关文章