jffs文件系统问题

dorke

今天做了一个实验，发现以下问题，大家帮忙分析解决一下

目标：
    擦除jffs文件系统，重新拷贝新的内容进入jffs

步骤：
    1、umount  jffs文件系统   /mnt/jffs   使用了强力umount  -fl
    2、使用erase命令擦除jffs
      3、mount jffs
      4、拷贝文件
    5、关机，再打开，看是否存在

问题：
    如果在第一步umount之前，通过telnet登录，并打开jffs文件夹  /mnt/jffs，执行完第4步，我们看到里面有内容，但是第5步后就没有内容了！很奇怪。

lichking_wang

不懂，期待解释

moon146

以下是个人理解，不对的不要见怪。
jffs是个日志文件系统，你用erese命令，把日志也删除了。
对文件的拷贝和删除操作都会记录在日志里面，不会十分实时的表现出来。
再次开机的时候，恢复日志，你的日志被删除了，为空，故什么都没有。
如果你用rm命令来删除，再拷贝的话，重启后文件应该就在了。

superfight

应该涉及到缓冲同步问题~

我看的是JFFS2 不知道JFFS通用不~

JFFS2有一个内存缓冲区来缓冲用户的操作,并不是实时将用户的操作写到flash设备上~ 所以在突然重启之前,最好使用sync命令来同步JFFS2和FLASH设备中的内容~

dorke

说错了，我用的就是jffs2，我已经使用了sync来同步过了，而且同步后还等待了几秒，根本不行，只要jffs2被打开，其他登录人员通过任何方式卸载、擦除都不行！

dorke

其实我之所以erase是因为某些时候，担心jffs已经被破坏掉了，包括他的节点，需要重新建立。估计常常玩jffs的人都遇到过这个问题，这个时候，你的rm（基于节点）就会失效，或者错误，因此，需要用erase将这块重新处理，然后再做jffs分区

superfight

呢就和我现在处理的问题差不多了~
这样的处理流程其实是越过了JFFS2层~
只要umount前还有进程在使用分区中的文件,呢么mount的时候就会恢复成umount的时候的状态~
最好还是在umount之前关闭所有打开分区的文件描述符 而且不要使用-l参数

dorke

我已经使用了fuser -m -k操作了，这个会关闭所有的程序的，但是还是不管用！

superfight

互相关注交流一下吧~

我现在读代码的结论是普通umount流程的话,会将分区对应的文件系统节点从super_blocks链表从剔除~ 呢么再mount的时候就会重建一个节点来同步flash和文件系统缓冲中的内容

而目前的流程的话 umount的时候不会将文件系统节点从super_blocks链表中剔除,导致再加载这个分区的时候会使用之前的文件系统节点~  不进行flash设备和缓冲数据的同步~  为什么umount不剔除节点是现在主要debug的目标,我是怀疑umount的时候文件系统计数器不为0,也就是open操作后没有close导致的

现在做试验,当一个进程open了分区之后没close就kill掉或者退出的话,在进程来看,他持有的文件描述符就找不到了~但是从计数器来说,这个文件描述符还没有关掉

从操作来说主要就是umount的-l参数~  用了这个参数,就能无视文件描述符的计数器直接卸载文件系统,但是却导致了之后的不同步,而不用这个参数,如果之前的进程退出之后没能成功的进行close操作,呢么之后就没办法卸载文件系统了

下个星期继续做这方面的测试~ 哈哈~

PS:兄弟你用的内核是什么版本的?~ 我的是2.4.19

dorke

用的是2.6.16
我还做过这个实验，开始文件挂在在/mnt/jffs2 下面，然后我umount掉他，重新换个地方mount到/mnt/temp下，结果还是一样，复制进取的文件，会丢失