[PATCH] Obsolete nodes that are unlinked when possible
joakim.tjernlund at transmode.se
Mon Mar 19 10:56:06 EDT 2007
On Mon, 2007-03-19 at 11:55 +0100, Ferenc Havasi wrote:
> Joakim Tjernlund írta:
> > Would bad things happen if an unclean reboot happens or will
> > you just loose some performance?
> There were many reason to set jffs2_can_mark_obsolete(c) to 0.
> As Artem wrote if we would like to enable we have to mark not only the
> node as obsolete but also the summary entry.
> It is not too easy because of the followings:
> - If you would like to modify the summary node on the flash it breaks
> the CRC of the summary node. A solutions can be: the ACCURATE bit should
> not included in the CRC. An other (worse) solution can be: when we
> obsolate a node we overwrite the summary magic with 0, and at the next
> mount the system will scan the erase block instead of using the summary
> (peformance penalty).
> - We also have to take care about not only the already written out
> summary. The summary is written out when the jffs2 close an erase block.
> If you want to mark obsolete a node in the unclosed eraseblock
> (nextblock) you should obsolate it in the collected summary, too.
> However it is not a big task, but also needs code modification and testing.
I see, however I think it is highly desirable to have both SUMMARY and
mark obsolete support as the FS becomes very dirty quickly on some
I did some tests with and without SUMMARY support compiled into
the kernel and strangely there wasn't a difference in boot
time on my system, 13 seconds in both cases. The FS image was the same
and had about 110 EB with summary info. Is something broken
wrt. summary support on recent kernels(2.6.20 on Powerpc)?
I have also noted that GC isn't performed unless there is lack of space
on flash. I have also noted that JFFS2 doesn't erase obsolete erase
blocks immediately even though the jffs2 code tries to do this(I known
my 2.4 kernel does this)
More information about the linux-mtd