suspend-to-disk

[Mitch Bradley]

Bernardo Innocenti wrote:
> Jordan Crouse wrote:
>
>   
>> I agree - the suspend to disk code in Linux is already quite mature and
>> ready for use - it only saves the pages it needs to.  The question here
>> isn't so much how to implement STD, since the concepts are pretty well
>> understood - but rather, can we implement it on a NAND device without
>> wasting too much precious storage space while avoiding lifetime issues
>> on the flash, and do it anywhere fast enough to make it worthwhile
>> during regular use?  These are questions I know not the answer to.
>>     
>
> Suspend2 advertises that it can even suspend to regular files, however
> it doesn't really understand filesystems.  It just stores the block
> list somewhere, in the same fashion of lilo.  So I don't think it will
> ever work with a compressed filesystem like jffs2.
>
>   
Assuming a 5-year laptop-lifetime goal and a FLASH lifetime of 100,000 
erase cycles:

1 year ~= 3E7 seconds.  5 years ~= 1.5E8 seconds.  1.5E8 / 100,000 = 
1500 sec = 25 minutes.

So you would have to hibernate every 25 minutes to wear out the FLASH 
during the laptop's design lifetime.  If we further assume that people 
(neuralis excluded) need to sleep about 1/3 of the time, the time goes 
down to 16 minutes.  So 8 minutes on, 8 minutes off during every waking 
hour of every day would start to wear out the FLASH.  That shouldn't be 
a problem.

We probably don't want to store the data in JFFS2.  Better to partition 
the NAND FLASH.

To "page in" from JFFS2, instead of storing block numbers, you would 
have to store references to JFFS2 data nodes.  That could be in the form 
of NAND page#,node_offset,data_offset to make reloading faster and less 
complicated.  The sizes of JFFS2 data nodes are variable-length and 
unrelated to the memory page size; you would have to store a list of 
them or something.