用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);
9. if((uid()==0||uid()==503)&&!isinstr(filename,"[")&&filename!="stap.log")
10. {
11. printf("name=%spid=%duid=%dino=%dname=%sfilename=%s/n",name,pid(),uid(),ino,devname,filename);
12. }
13. }

输出结果让我有些意外：

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~~