摘要：
为了解决这个问题，我编写了一个简单的systemtap脚本来分析文件编写操作（“stap.log”）｛printf；｝｝输出结果让我很惊讶：name=do_sync_writepid=22542uid=0ino=324338name=sda1filename=sqlite_lVkvYHYHUTVO2SS journalname=do_ssync_writepid=22542uid=0ino=324338name=sda1filename=sqlite_lvkvYHUTVO2S journalname=sda_1sync_writepid=225442uid=0ino=324338name=sda1file name=sqlite_1VkvYHUTvo2SS johannalname=do_sync_writepid=22542uid=20ino=324338 name=sda1file name=sqlite_1lVkvYHYHUTVO2SS日志名称=do_sync_writepid=22542uid=0ino=324338name=sda1filename=sqlite_lVkvYHUTVO2S日志名称=do _sync_wwritepid=22542 uid=0ino=324316name=sda1file名称=sqlite_lvkvYHYHVOVO2SSname=do_ssync_writepid=22542uid=0ino=324316name=sda1filename名称=sqlite _ lVkvyYHUTVO2sSname=do_sync-writepid=42542uid=0ino=324316name=sda1file文件名=sqlite_1VkvYHVO2SSname _ lVkvYHYHUTVO2SSname=do_同步_writepid=22542uid=0ino=324316name=sda1filename=sqlite_ lVkvYHYHUTVO2SSname=do_sync_ writepid=22542uid=0ino=324316name=sda1filename=sqlite_ LVkvYHUTVO2S实际上是一个sqlite，它执行了许多临时文件写入操作。它一启动就完成了800多次写入操作。添加记录需要24次写入，包括21次临时文件写入。当我检查sqlite进程打开的文件时，我发现临时文件放在/var/tmp下。这就是问题所在。这不是临时文件系统。我修改了sqlite代码，闪存写入操作减少到原来的1/8。
用systemtap分析磁盘写入操作
转载时请注明出处和作者联系方式
作者联系方式：李先静 <xianjimli at hotmail dot com>
这几天发现有好几块broncho开发板的FLASH坏了，broncho使用的SLC，现在的SLC写入寿命至少在10W次以上，尽管现在的测试要比正常使用高得多，也没有可能在不到一个月就坏了啊。不过最近听人说jffs2的磨损均衡只是在剩余空间中进行，而broncho的剩余空间并不多，这让我觉得事态有些严重。
得做点什么才行。我先想到的是文件操作可能存在问题，没有多少地方需要进行写入操作啊，即使均衡不好，flash也不应该坏得这么快啊。为了揭开这个谜底，我写了个简单的systemtap脚本，用来分析文件写入操作。
- probe kernel.function("do_sync_write")
- {
- name="do_sync_write";
- dev = __file_dev($filp)
- devname = __find_bdevname(dev, __file_bdev($filp))
- ino = __file_ino($filp)
- filename = __file_filename($filp);
- if((uid()==0 || uid()== 503) && !isinstr(filename, "[") && filename != "stap.log")
- {
- printf("name=%s pid=%d uid=%d ino=%d name=%s filename=%s/n", name, pid(), uid(), ino, devname, filename);
- }
- }
输出结果让我有些意外：
- name=do_sync_write pid=22542 uid=0 ino=324338 name=sda1 filename=sqlite_lVkvYHYHUTVO2SS-journal
- name=do_sync_write pid=22542 uid=0 ino=324338 name=sda1 filename=sqlite_lVkvYHYHUTVO2SS-journal
- name=do_sync_write pid=22542 uid=0 ino=324338 name=sda1 filename=sqlite_lVkvYHYHUTVO2SS-journal
- name=do_sync_write pid=22542 uid=0 ino=324338 name=sda1 filename=sqlite_lVkvYHYHUTVO2SS-journal
- name=do_sync_write pid=22542 uid=0 ino=324338 name=sda1 filename=sqlite_lVkvYHYHUTVO2SS-journal
- name=do_sync_write pid=22542 uid=0 ino=324316 name=sda1 filename=sqlite_lVkvYHYHUTVO2SS
- name=do_sync_write pid=22542 uid=0 ino=324316 name=sda1 filename=sqlite_lVkvYHYHUTVO2SS
- name=do_sync_write pid=22542 uid=0 ino=324316 name=sda1 filename=sqlite_lVkvYHYHUTVO2SS
- name=do_sync_write pid=22542 uid=0 ino=324316 name=sda1 filename=sqlite_lVkvYHYHUTVO2SS
- 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~~