JFFS2 node versioning problem?
Dmitry Bazhenov
atrey at emcraft.com
Wed May 3 10:28:51 EDT 2006
On Wednesday 03 May 2006 16:02, Artem B. Bityutskiy wrote:
> Can it happen with a real-life flash device? If it can, we have to
> switch to 64-bit versions.
I think it can happen. I can imagine at least one scenario where such
situation can occur. Of course, in normal circumstances it is hardly possible
but in the case of a powerfail it can be.
1. Assume, upon a call to jffs2_commit_write() function the
f->highest_version has the maximum value.
2. jffs2_commit_write() increments f->highest_version which becomes 0.
3. jffs2_commit_write() invokes jffs2_write_dnode() with version=0.
5. Powerfail before obsoleting least recent overlapping nodes.
6. After reset, the scan process finds two(if were only one node for the
commited page before) valid nodes wich refer to the same region. It places
the least recent node which has the maximum version number at the end of
the node list.
7. When jffs2_read_inode() function is invoked, the node with the biggest
version number is added last, thus, obsoleting all overlapping nodes.
The most recent inode is obsoleted as well. --> Bug.
As a workaround I suggest to obsolete previous nodes before writing the new
one. In case of powerfail there will be holes in data which can be easily
recognized during inode reading.
--
Regards,
Dmitry
More information about the linux-mtd
mailing list