Jffs2 and big file = very slow jffs2_garbage_collect_pass

[Ricard Wanderlof]

On Wed, 23 Jan 2008, Jörn Engel wrote:

>> One problem may be what to do when the system is powered down. If we don't
>> store the error counters in the flash (or some other non-volatile place),
>> then each time the system is powered up, all the error counters will be
>> reset.
>
> Exactly.  If the information we need to detect problems is not stored in
> the filesystem, it is useless.  Maybe it would work for a very
> specialized system to keep that information in DRAM or NVRAM, but in
> general it will get lost.
>
> As a matter of principle logfs does not do any special things for special
> systems.  If you have a nice optimization, it has to work for everyone.
> If it doesn't, your systems behaves differently from everyone else's
> systems.  So whatever bugs you have cannot be reproduced by anyone else.

Very true.

Perhaps it's possible to devise something that at least accomplishes part 
of the goal. Such as when writing a new block, also write some statistical 
information such as the number of read accesses since the previous write 
(or power up), or the reason for writing (new data, gc because of 
bitflips, ...) and a write counter. Something of that nature.

> High wearout means short time between two writes.  Which also means few
> reads between two writes.
>
> As long as the write rate (wear rate) remains roughly constant, high
> wear doesn't seem to cause any problems.  The block's ability to retain
> information degrades, but that doesn't matter because it doesn't have to
> retain the information for a long time.

I'd be a bit wary of this with NAND chips some of which have a 100 000 
maximum erase/write cycle specification, though. And I think that 
especially when nearing the maximum value and going beyond it, that there 
is some bit decay occurring over time and not just from reading.

On the other hand, with 100 000 write cycles total, and assuming a product 
lifetime of 3 years, we end up with over 90 permitted write/erase cycles 
per day. Depending on the situation, it might be quite ok to take 
advantage over this.

/Ricard
--
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30