JFFS2 mount time
dedekind at oktetlabs.ru
Mon Oct 25 06:56:29 EDT 2004
> Yes, I think there are three kinds of nodes:
> - type A contains relevant amount of data which is not needed at mount
> time (jffs2_raw_inode)
> - type B is (almost) fully needed at mount time (jffs2_raw_dirent)
> - type C is any other (unkown, developements in the future...)
> To achieve as much mount time speed up as possible I think we should
> distinguish them.
This is what I really do not like.
Ok, let us discuss now only this topic. Lt I explain why I believe it is
vad and very *unnatural* to introduce two or more kinds of blocks.
The example of JFFS2 change that I consider natural is the introduction
of new node type. It is natural, because of when JFFS2 was designed,
this possibility was foreseen and taken into account. It is relatively
easy to do this. It is possible to do this and do not affect other
things in the JFFS2.
Conversely, the introducing several block types was not foreseen in the
JFFS2 design. And all things in the JFFS2 are coded with the assumption
all the blocks are equivalent.
This is my point view on the issue in general.
Now I will try to illustrate why I think so.
1. In JFFS2 there are several lists of blocks - clean_list, dirty_list,
very_dirty_list?. Are you going to introduce clean_list_typeA,
dirty_list_typeA, very_dirty_list_typeA, clean_list_typeB,
dirty_list_typeB, very_dirty_list_typeB ?
2. Just do 'grep "_list" * | grep -e "\(dirty\)\|\(very\)"' and see how
many places in JFFS2 where these lists are changed. Do you think it is
natural to introduce 3 more lists? I believe not. What if somebody else
will introduce one more type of block?
3. There is write buffer in the JFFS2 which is used in case of NAND. Are
you going to have two wbufs? This is also significant change.
4. Now the GC just gives one block, and moves all the valid nodes to
another one. In your case (if you have the JFFS2 image which was created
by older code, without your patch, where all node types are mixed),
you will need to move one type of nodes to one block, another to the
So, I think you will be needed to change many things in JFFS2. You have
a risk to hit on a can of worms.
So, do you agree that this change is *unnatural* ?
>> 4. It seems for me you will need to increase the number of blocks
>> which are reserved for the garbage collection (double ?). This is also
>> minor drawback.
> I don't understand what do you mean here
I mean the sb->resv_blocks_gcmerge and related. You will need to
increase it, which is not very good.
Best regards, Artem B. Bityuckiy
Oktet Labs (St. Petersburg), Software Engineer.
+78124286709 (office) +79112449030 (mobile)
E-mail: dedekind at oktetlabs.ru, web: http://www.oktetlabs.ru
More information about the linux-mtd