Re: inode checkpoints

["Artem B. Bityuckiy" <abityuckiy@yandex.ru>]

Hello Guys.

Unfortunately, I hit on very painful trouble while trying to 
design/implement checkpoints (ICP) ...

Obviously, ICP must contain all information, which is required to build 
the inode cache. These are: offset, size and *version*. The problem is 
in version.

At first I thought that in order to create ICP for some regfile inode, 
we just need to be sure that the inode cache for this regfile exists. 
But! I've overseen the fact that *there is no versions in the inode 
cache* :-(

The inode cache (struct jffs2_inode_info) contains fragtree which has 
struct jffs2_full_dnode objects. But these objects have no version field...

So, I see two ways out:

1. Add the version field to the struct jffs2_full_dnode objects.
This also means that the struct jffs2_tmp_dnode_info structure won't be 
needed anymore.

The advantage of such approach is that the JFFS2 will be more simple 
since one data structure will be removed. I like the KISS principle.

The drawback is that the inode cache will eat more memory. But this 
isn't in-core object, just cache, so I don't think this is a big 
disadvantage.

2. Don't use the inode cache at all. This is bad because in order to 
build the inode cache we'll need to read *all* the node headers, even if 
there is existing inode cache.

I believe this approach is bad and too heavyweight. Moreover, just 
imagine the situation when the GC has fount an ICP ant wants to 
determine if it valid or obsolete. Obsolete means that (1) there is 
newer ICP with higher version (simple case) or (2) all (or most) the 
nodes which are described by the ICP aren't valid anymore (complicated 
case). The second case means that we must read the ICPs lowest_version 
and highest_version and count how many valid nodes with versions within 
this interval exist. But we have NO versions even if the inode cache is 
present. I don't think it is a good idea if the GC will head all the 
node's headers...

What do you guys think? Any advices/ideas?

Thanks.

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.