Author Topic: Fixing jffs2 file systems  (Read 1753 times)

iamasmith

  • Hero Member
  • *****
  • Posts: 1248
    • View Profile
Fixing jffs2 file systems
« on: October 22, 2004, 11:52:01 am »
I have recently been playing with various ROMs and returning to my Cacko 1.21b install which is excellent in the functionality and I'm loath to change it at present.

I was using NAND Backup/Restore and I noticed that I was getting jffs2 errors about some inodes associated with files that no longer existed - the messages then said unable to remove the inodes, these errors persisted over as many reboots as I had care to try - this was immediately after a NAND restore so there were two possibilities, either I had some duff NAND flash or I had captured a corrupt NAND image. I ran a full NAND check and it reported 0 errors so in the end I ended up restoring the NAND flash, taking a backup of it, untarring the backup and diffing all the package and library files just to be certain that they were intact (phew they were!), using the 3rd option on the Japanese startup menu (Hold down OK on battery insert boot) to erase the user partition and finally restoring the backup. This got me back to a clean state with no duff inodes which the kernel couldn't delete (as was the case with what I had before).

My observations on this are that such corruption shouldn't really happen but if you are playing and you do manage to crash the Z stone dead then it's possible. What you should then do is really examine dmesg output and if you see jffs2 errors probably shutdown and restart again to see if the kernel checks managed to clean it up.

Now the only recourse that I had to clean up and retrieve my data was to format the user partition and tar everything back, however, this is going to be a problem with pdaXrom which had a writeable root and also with OZ because it has writeable root and for some reason seems NOT to erase the home partition with the aforesaid menu.

I would be VERY interested if anyone has any suggestions on how to fsck these mtd partitions and to force deletion of orphaned inodes that a standard check can't get rid of, maybe this could be achieved by booting off an SD or CF card with the jffs2 partitions unmounted but there doesn't seem to be an fsck.jffs2 knocking around.

Any good ideas ?, this would probably be useful, as I mentioned, for pdaXrom and OE guys too.

- Andy
« Last Edit: October 22, 2004, 11:53:32 am by iamasmith »
OpenBSD 4.2 -current on full 4Gb of SL-C3000
Microdrive replaced with 4Gb SanDisk Extreme III card

sonicbuddha

  • Newbie
  • *
  • Posts: 38
    • View Profile
Fixing jffs2 file systems
« Reply #1 on: November 03, 2004, 04:24:11 pm »
I've had this same problem after removing my gcc-headers ipk on pdaXrom rc5.  It appears that the journaling file system is trying to rectify the absence of files located in a directory that no longer exists.  If there is any way to fix this beyond reinstalling, I'd like to know.
C860 running pdaXrom 1.1.0 RC9
Full 121Mb root
home on Kingston 512Mb SD card
Pretec WiFi

iamasmith

  • Hero Member
  • *****
  • Posts: 1248
    • View Profile
Fixing jffs2 file systems
« Reply #2 on: November 11, 2004, 07:17:03 am »
OK, after trawling the archives on lists.infradead.org and reading some of the background on jffs2 it seems that there are some unique aspects to jffs2 that I wasn't aware of before.

jffs2 is actually fairly smart and given that it is targetted at writable flash file systems it implements write minimisation and wear levelling technologies.

It also tells the user a LOT of stuff that may be seen as alarming but actually isn't all that alarming.

One of the features of jffs2 is the garbage collector which maintains a queue of stuff to be done when space gets tight, such as erasing blocks to free them and given that jffs2 has a major design goal of reducing the number of writes then it only does this when it actually has to.

Various posts on the mtd lists suggested that if you are getting errors like this and are really concerned about them try filling up your file system which will make the garbage collector clean these areas up.

Basically the verdict was don't worry about it.

I thought I had a hopelessly screwed fs, it turns out I didn't.

- Andy
OpenBSD 4.2 -current on full 4Gb of SL-C3000
Microdrive replaced with 4Gb SanDisk Extreme III card