Great jffs2 speedup

[Artem B. Bityutskiy]

Jörn Engel wrote:
> On Thu, 29 September 2005 13:59:53 +0400, Artem B. Bityutskiy 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.
> 
> 
> Dummy argument.  Wear levelling is just a means to avoid the real
> problem - early wear-out of specific blocks.  Spending one erase block
> for cs is pretty sane, as long as this block doesn't wear-out well
> before the rest.
"As long as" is the essential part. If it is true - nice. In general 
this can't be true. And, anticipating your remark, I agree that it still 
may have its place. :-)

>>>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...
> 
> 
> How?
The same way as above unless you evenly rotete the CS eraseblock. And if 
("as long as" == TRUE) then all is ok.

> CS definitely doesn't solve all problems and it trades the mount time
> for additional writes - plus the special first erase block.  Still, it
> may have its place.
Thanks, I have no doubts. :-)

-- 
Best Regards,
Artem B. Bityuckiy,
St.-Petersburg, Russia.