JFFS2 mount time
Artem Bityuckiy
dedekind at oktetlabs.ru
Tue Oct 26 07:05:50 EDT 2004
Ferenc,
> Is it sure than only one non-full erase block is in the filesystem?
> Non-full means here that there is some nodes already in that, but also
> there is some free space at the end of it.
I didn't analyse this accurately, but my vision is that there is one
current block (c->nextblock). Even GC moves nodes to it. This is because
the jffs2_do_reserve_space() is always used (even by GC), and the
jffs2_do_reserve_space() always uses c->nextblock.
> As I see jffs2_do_reserve space is called before inode/... allocation in
> most cases. So at that time the summary information is not know - but at
> writing it have to be known certainly.
May be... From another hand you may write summary every time the
jffs2_reserve_space() fetches new block from the free_list...
Anyway, this is not fundamental...
> You may misunderstood me. In the previous letter I wrote: "So you
> convinced me. We will change the design of summary. The inodes and
> dirents will be also in the summary."
>
> So now we do plan to store dirents in the summary. :)
OK, sorry. :-)
> Let see how it work, and after we can make it more optimal :)
Agree :-)
Also, please, take into account that there may be checkpoint nodes (I'm
implementing this). So, I think you need to have a generic mechanism to
add new node types to your summary.
Also, I think it is good to have a generic mechanism to just refer some
nodes from summaries (for example, direntries with long names or
something else).
Thank you for conversation too.
:-)
--
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
mailing list