Sometimes when a program locks the system and I'm forced to reboot, there will be some error (bad checksum and inode) in the file system. I think I need to fix this with fsck, but when I ran

fsck /dev/mtdblock/3

I got the error:

fsck.jffs2: not found.

Where can I find this package? Or should I ever fix it this way?

(I mostly had this in Cacko but the pdaXrom is more responsive so I asked it here.)

I think this should probably be on the wiki of frequently asked questions.

There is probably more detail in one of the several responses that I have already made to this 'non issue' so I will be brief here.

jffs2 avoids writing updates until it is absolutely necessary. This is even across reboots.

The actual jffs driver is very chatty and shows the state inconsistency that occurs on the actual file system without taking into account what is pending in the journal. The actual access to the file system, however, does take into account the information stored in the journal and will provide you with a consistent file system.

The percieved errors are almost certainly non existant, you will see inode errors and errors about files no longer existing during the boot phase, this is quite normal for a jffs2 file system that has had any form of file alteration - these should be ignored unless you are actuall experiencing inconsistencies. The advice then is to reinstall and restore.

Why does jffs2 do this? - it does it because NAND flash has a limited number of write cycles and it does absolutely everything it can to limit the number of writes to the same block. This behaviour is by design.

-Andy

Thanks Andy.

Do you mean if I see the error again and again and never goes away (That's what I have on my C1000), then I should do a full restore? Do I have a way to "FORCE" JFFS2 to do an actual write to see if there is a real error? After all, restrong an NAND backup will end up with writing the WHOLE flash memory.

Also, by "wiki" do you mean the pdaXrom website or the one on oesf?

This isn't a pdaXrom related issue per se, it is relevent to all Zaurus models that use jffs2 file systems.

You will see the error on reboot over and over again until the file system and journal decide that portion of the flash should be written.. usually this happens only when the file system fills sufficiently.

Take a look at the redhat jffs2 project for more information.

http://sources.redhat.com/jffs2/

I'm bringing this up again because I think I've found some new evidence:

I'm having trouble with SCIM on beta3 on C1000. Once I crashed the machine and had to reboot, after reboot (take out battery -> power on), some SCIM files seemed broken. Then I removed and reinstalled all SCIM and its dependency. It worked. But then I reboot again(halt -> take out battery -> power on), what I saw is the SAME files were broken!

I doubt that the files were NOT really written to the NAND flash when I reinstalled them, they might be just changed in the RAM (I could be wrong) and therefore lost during reboot. If this is the case, I think I really need some tool to maintain the JFFS2 file system (or the underlying driver).

I agree... I mean... I doesnt affect any performance on my end... but it is just bugs me when I reboot...

Late

OK. So I know I'm not the only one who has this problem.

its not a problem its designed that way.

I mean... I dont think it is a problem... but is there a way to force the writes?

Late

init 6

It only writes during a proper shutdown or when it runs out of buffer.

I don't believe that fixes it... I will try when I get home... but "reboot" is the same as a "init 6"... and I've done many reboots with no hope... unless reboot leaves out something running in init 6... but I thought "reboot" basicly a symlink to lauch init 6...


Late

On pdaXrom beta1, reboot is actually a link to "halt".

TJBK_TJB,

Do you mean that if the system shutdown abnormally, the changes to the JFFS2 file system could be lost? This is a very important point because I rarely have the incorrect inodes on my 7500C, but a LOT on my C1000. Could this mean that the shutdown function of C1000 is not very decent?

--edit--
I looked at iamasmith's post and got a better understanding of the issue. I think I have similiar issues with "sommi", (who never pinned back, BTW), I just need to ensure the changes I made to files will survive a reboot (either with reboot, halt ot init 6).

seems like in most cases suppressing the messgaes would be a better "cure" than forcing write....

This article here answered some of my questions:
http://www.linux-mtd.infradead.org/faq/jffs2.html

My problem is that something is really LOST in my flash during reboot. So I need to ensure a physical write to NAND after I add some software or change some important configuration.

The article mentioned that fsync() or sync() can do that. Also, the "/proc/sys/vm/dirty_expire_centisecs" controls the timeout for writing to NAND. I checked that pdaXrom beta1 doesn't have that in /proc while OZ has it.

It also mentioned that mounting root as readonly before shutdown will force the write. I don't know if these are all properly setup in pdaXrom beta3 for C1000 release.

Many (most?) Linux systems do this, so it seems like the best way. Interestingly enough though, /etc/rc.d/init.d/halt appears remount every filesystem except jffs2 (and swap/proc etc)...

(I have an SL6000, not a C1000, but I would have thought this stuff is the same)

Do you mean I can fix this by adding the line for remounting JFFS2 in the script?

actually, it remounts / as ro which is the jffs2 partition

Does it? The version of the script on my zaurus only (it appears) does the following:

a ) turn off swap
b ) 3 attempts at unmounting network filesystems
c ) remounts (specifically only) ext2,ext3,minix,vfat and reiserfs filesystems as read-only

It doesn't look like it does anything with the jffs2 partition... (I don't know a lot about jffs2, so here is where you tell me I'm wrong )