用systemtap分析磁盘写入操作

用systemtap分析磁盘写入操作

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


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

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

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

 
输出结果让我有些意外：

1. name=do_sync_write pid=22542 uid=0 ino=324338 name=sda1 filename=sqlite_lVkvYHYHUTVO2SS-journal
2. name=do_sync_write pid=22542 uid=0 ino=324338 name=sda1 filename=sqlite_lVkvYHYHUTVO2SS-journal
3. name=do_sync_write pid=22542 uid=0 ino=324338 name=sda1 filename=sqlite_lVkvYHYHUTVO2SS-journal
4. name=do_sync_write pid=22542 uid=0 ino=324338 name=sda1 filename=sqlite_lVkvYHYHUTVO2SS-journal
5. name=do_sync_write pid=22542 uid=0 ino=324338 name=sda1 filename=sqlite_lVkvYHYHUTVO2SS-journal
6. name=do_sync_write pid=22542 uid=0 ino=324316 name=sda1 filename=sqlite_lVkvYHYHUTVO2SS
7. name=do_sync_write pid=22542 uid=0 ino=324316 name=sda1 filename=sqlite_lVkvYHYHUTVO2SS
8. name=do_sync_write pid=22542 uid=0 ino=324316 name=sda1 filename=sqlite_lVkvYHYHUTVO2SS
9. name=do_sync_write pid=22542 uid=0 ino=324316 name=sda1 filename=sqlite_lVkvYHYHUTVO2SS
10. name=do_sync_write pid=22542 uid=0 ino=324316 name=sda1 filename=sqlite_lVkvYHYHUTVO2SS

居然是sqlite做了大量的临时文件写入操作，仅仅是起动一次就做了800多次写入操作。增加一条记录要写入24次，其中临时文件写入占21次。如果使用的临时文件系统，那没事儿，因为临时文件系统是用内存来模拟的，写多少次都不怕，默认的临时文件系统mount在/tmp下。而我在检查sqlite进程打开的文件时，发现临时文件放在/var/tmp下，问题就出在这里，这不是临时文件系统。我修改了sqlite的代码，对flash的写入操作降为原来的1/8。

希望这个改动确实有效。

~~end~~