Great jffs2 speedup

[Ferenc Havasi]

Artem B. Bityutskiy wrote:

> Ferenc Havasi wrote:
>
>> The first way stores a reference in the first (usable) erase block. (If
>> it is not free, it moves the data to somewhere else, and reserve). It
>> stores only a reference to it at umount, and a "mount-log" at mount
>> (just to mark that it is invalid in case of unclean umount). It means
>> one page write at mount, one page write at umount. If the erase block
>> consist 16 pages than it is necesarry to erase the first erase block
>> after every 8 mounts. So the typical timelife of it is about 8*100.000
>> mounting, I think it is big enough.
>
> This spoils the overall wear-leveling, which is no good. But should work.

It concept of goodness is subjective. IMHO if someting has such a design
what works well and fit to the concept of the real thing (the flash)
that is good.

>> The other way is to specify the cenratlized summary information with
>> mount option (not to use the first erase block to store this pointer).
>> In this case some other system have to store it (typically on an other
>> file system), and the new location after umount can be read using sysfs.
>
> This also spoils wear-levelling...

It think it is the method which is really does not spoil the
wear-leveling. The selection of the storing place uses exactly the same
function what JFFS2 uses to store any other data.

> And I don't like CS in general as it is not tolerant to unclean
> reboots... Albeit, if this does not matter to a specific system - this
> will work.

Yes, CS was designed for clean umounts. And it can be combinated with
EBS, too.

> Nevertheless, I don't believe CS will make JFFS2 usable on 256MB
> flashes, due to memory consumprion issues. Nor it will not (IMO) make
> it scalable, which is sad :-(

Yes, it does not solve the memory problems of JFFS2. It is yet another
mount time speed up.

Bye,
Ferenc