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