Re: inode checkpoints

["Artem B. Bityuckiy" <dedekind@mail.ru>]

Artem B. Bityuckiy wrote:
> 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.
Moreover, there is the 'ofs' field in the jffs2_full_dnode which isn't 
really needed since the sabe information is in the raw->flash_offset 
field. So, we can for example add 'version' and remove 'ofs' field. The 
size won't change, the JFFS2 will be a bit simpler. Only small overhead 
(need to dereference pointer to get the ofs) will be introduced.

> 
> 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. Bityckiy