jffs2_get_inode_nodes(): Data CRC failed on NAND device
Hi,
I have a board with samsung K9F5608UOC nand flash and mpc5200 ppc processor.
I run a 2.4.25 kernel (yes I know it's very old) on this board with mtd from 20041007 snapshot.
I burn a jffs2 image on the nand with "nandwrite -j" (from nfs). All is ok and the filesystem is good but when I reboot the board or when I remove the power "violently", I get somes messages like this :
/Empty flash at 0x009826d8 ends at 0x00982800jffs2_get_inode_nodes(): Data CRC failed on node at 0x00cc0f90: Read 0x6e17981a, calculated 0x4614a389 /And I get one more message each time I reboot the board. But the filesystem doesn't seem corrupted.
If I umount / before rebooting, I don't have one more error message at the next reboot.
Here is my kernel command line (passed from uboot). Do I forget some mount options ?
/Kernel command line: root=/dev/mtdblock3 rw ip=172.16.48.19:172.16.16.240:172.16 .254.254:255.255.0.0::eth0:off panic=1 /
Do you have any idea about where the problem could come from ?
Frederic.
PS: sorry for my poor english.
Quoted 4 lines · Frédéric Janot
Hi,
I have a board with samsung K9F5608UOC nand flash and mpc5200 ppc processor.
JFFS2 on NAND flash uses a page buffer. It is flushed to the flash when it is full, or when you do fsync, sync or umount.
Quoted 1 line
when I reboot the board or when I remove the power "violently"
Some data may remain in the page buffer and is never written to the Flash.
Quoted 2 lines
jffs2_get_inode_nodes(): Data CRC failed on node at0x00cc0f90: Read0x6e17981a, calculated0x4614a389
Well obviously a node was partly written to flash and the end of the node remained in the cache and was never written. This means you lost some data.
Quoted 2 lines
/And I get one more message each time I reboot the board. But the filesystem doesn't seem corrupted.
It is a warning only. The remainder of the file system will probably still work. Only the last operation(s) before reboot are lost.
Quoted 2 lines
If I umount / before rebooting, I don't have one more error message at the next reboot.
This is correct procedure if you don't want to lose any data.
Quoted 1 line
Do you have any idea about where the problem could come from ?
There is no problem. This is standard JFFS2 processing. Nodes with wrong CRCs (partly written for instance) are ignored and not taken in account when building the FS tree and files.
Estelle
Estelle,
Thanks for this very fast answer !!!
Quoted 4 lines · Estelle HAMMACHE
JFFS2 on NAND flash uses a page buffer. It is flushed to the flash when it is full, or when you do fsync, sync or umount.
Does that mean that I have to call fsync each time after fclose a file ?
Even if I do not edit some files, I get this kind of error. Does that mean something (jffs2 itself or other) write some data to the flash all the time ?
Quoted 4 lines
Some data may remain in the page buffer and is never written to the Flash.
So I really loose some data :(
Quoted 8 lines
Quoted 4 lines
If I umount / before rebooting, I don't have one more error message at the next reboot.
This is correct procedure if you don't want to lose any data.
It is an embedded board without power supervisor. I cannot detect when the customer power down the board :(
Frederic
Quoted 7 lines · Frédéric Janot
Quoted 3 lines
JFFS2 on NAND flash uses a page buffer. It is flushed to the flash when it is full, or when you do fsync, sync or umount.
Does that mean that I have to call fsync each time after fclose a file ? Even if I do not edit some files, I get this kind of error. Does that mean something (jffs2 itself or other) write some data to the flash all the time ?
No, jffs2 does not write data just for fun. There is some application, script, daemon writing/modifying file(s).
tglx
Quoted 5 lines · Thomas Gleixner
Quoted 4 lines · Frédéric Janot
Quoted 3 lines
JFFS2 on NAND flash uses a page buffer. It is flushed to the flash when it is full, or when you do fsync, sync or umount.
Does that mean that I have to call fsync each time after fclose a file ?
Yes. It's precisely the same as with other file systems. If you write to a file, close it and then lose power immediately, your data may be lost. It's not guaranteed to be on the medium until you sync.
Quoted 6 lines
Quoted 3 lines
Even if I do not edit some files, I get this kind of error. Does that mean something (jffs2 itself or other) write some data to the flash all the time ?
No, jffs2 does not write data just for fun. There is some application, script, daemon writing/modifying file(s).
Or garbage collection, but in that case no data are lost. It was just copying from one part of the flash to another, and the old copy will still be intact.
Signature · 1 line
dwmw2
Hi,
Quoted 6 lines
Quoted 3 lines
Quoted 3 lines
Quoted 2 lines
JFFS2 on NAND flash uses a page buffer. It is flushed to the flash when it is full, or when you do fsync, sync or umount.
Does that mean that I have to call fsync each time after fclose a file ?
Yes. It's precisely the same as with other file systems. If you write to a file, close it and then lose power immediately, your data may be lost. It's not guaranteed to be on the medium until you sync.
Well, as someone told me the other day on the IRC-channel, the writebuffer is flushed automatically if the buffer has not been accessed for X (2?) seconds (controlled by the VFS, right?)...
Correct me if I'm wrong...
// Martin
Quoted 5 lines · Martin Egholm Nielsen
Well, as someone told me the other day on the IRC-channel, the writebuffer is flushed automatically if the buffer has not been accessed for X (2?) seconds (controlled by the VFS, right?)...
Correct me if I'm wrong...
Not quite. The write buffer is flushed every 5 seconds, unless you tune it using the /proc entry. It's controlled by kupdated, which syncs the supers, which flushes the write buffer in JFFS2.
If the write buffer contains GC data, that isn't flushed at all.
josh
Quoted 5 lines · Josh Boyer
Quoted 4 lines · Martin Egholm Nielsen
Well, as someone told me the other day on the IRC-channel, the writebuffer is flushed automatically if the buffer has not been accessed for X (2?) seconds (controlled by the VFS, right?)...
Quoted 7 lines
Quoted 1 line
Correct me if I'm wrong...
Not quite. The write buffer is flushed every 5 seconds, unless you tune it using the /proc entry. It's controlled by kupdated, which syncs the supers, which flushes the write buffer in JFFS2.
If the write buffer contains GC data, that isn't flushed at all.
Just to clarify that, if the buffer contains _only_ GC data it isn't flushed. If it contains GC + inode data, all of that data is.
josh
Quoted 5 lines
Quoted 5 lines
Quoted 2 lines
Well, as someone told me the other day on the IRC-channel, the writebuffer is flushed automatically if the buffer has not been accessed for X (2?) seconds (controlled by the VFS, right?)... Correct me if I'm wrong...
Not quite. The write buffer is flushed every 5 seconds, unless you tune it using the /proc entry. It's controlled by kupdated, which syncs the supers, which flushes the write buffer in JFFS2.
But this might be the better solution for Frederic, instead of poluting his code with fsync's. That is, just tune the /proc entry (which one?) to a value suitable for your needs - e.g. 2 secs.
Quoted 3 lines
Quoted 1 line
If the write buffer contains GC data, that isn't flushed at all.
Just to clarify that, if the buffer contains _only_ GC data it isn't flushed. If it contains GC + inode data, all of that data is.
:o)
// Martin
Quoted 5 lines · Frédéric Janot
Quoted 1 line
Does that mean that I have to call fsync each time after fclose a file ? Even if I do not edit some files, I get this kind of error. Does that mean something (jffs2 itself or other) write some data to the flash all the time ?
Sorta. See below.
Quoted 6 lines
Quoted 5 lines
Some data may remain in the page buffer and is never written to the Flash.
So I really loose some data :(
Maybe not. It could be a GC node that was cut short. In that case, you shouldn't loose any data since the original node should still be in place.
Quoted 2 lines
It is an embedded board without power supervisor. I cannot detect when the customer power down the board :(
If you are worried about data loss, then fsync/sync is probably what you should do.
josh