Re: JFFS2 node versioning problem?

Josh Boyer
2006-05-03T15:08:01Z

On 5/3/06, Dmitry Bazhenov <atrey@emcraft.com> wrote:
> 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.

On NAND flash (and some NOR flash chips), the nodes can't physically
be marked obsolete on the chip. So JFFS2 has to figure it all out at
scan time for those regardless.

What Artem was asking is if it was physically possible to have a
file/directory with 4294967296 versions to being with. Take a 1 byte
file as an example. If that was the only file on the whole device,
and you had that many versions of it you'd have:

68 bytes overhead per version + 1 byte of data per version =
296352743424 bytes required to store.

That's 276 GiB. Which isn't even sane for JFFS2 anyway.

josh