NAND Full Requirement

[Erik Garrison]

On Tue, Jul 22, 2008 at 04:22:33PM -0400, pgf at laptop.org wrote:
> erik wrote:
>  > On Tue, Jul 22, 2008 at 04:01:35PM -0400, Greg Smith wrote:
>  > > Hi All,
>  > > 
>  > > Here's the requirement for Uruguay NAND full situation.
>  > > 
>  > > I need this fixed ASAP.
>  > > 
>  > > - The XO must always boot up to sugar including allowing access to the 
>  > > journal. That is no matter the fullness of the NAND
>  > > - If the NAND has less than nnMB (50?) free, warn the user that they are 
>  > > low on space.
>  > > - Must be installable on 656 in the Uruguay configuration
>  > > - Must not delete any user created files
>  > > - Must not disable any activities or other functionality
>  > > 
>  > > So far they have:
>  > > - a dialog box which warns when you get low on space
>  > > - Chris's script which allows deleting stuff automaticaly but probably 
>  > > user stuff
>  > > 
>  > > What else they want, not sure... I will talk to Emliano ASAP and let you 
>  > >   know.
>  > > 
>  > > Erik will propose one solution (related to RamFS I believe).
>  > > 
>  > 
>  > See: http://dev.laptop.org/ticket/7587#comment:4
>  > 
>  > On boot, check NAND discomfort level.  If high, use unionfs(4) to mount
>  > a read/write tmpfs over top of a read-only jffs2 rootfs.  Set unionfs
>  > flags to enable file deletion from the 'ro' root partition (or if this
>  > is impossible, mount the fs in another location to allow deletions).
>  > Set a flag to tell olpc-session or Sugar to enter into a deletion
>  > dialog.  
>  > 
>  > Benefits:
>  > This solution theoretically allows all software to run an a NAND-full
>  > machine.  Thus students who arrive at school with a NAND-full machine
>  > could still work with their XO through lessons and manage flash cleanup
>  > as time is available.  Requires minimal code-level changes to enable.
> 
> what happens when they fill up tmpfs while still working through
> lessons?
> 

The most motivating benefit is that we can have a graphical deletion
interface running within the typical UI with minimal code changes.  (I
should have first mentioned that.)  Beyond that, this approach gives
users a good degree of flexibility in figuring out how and when to
resolve the problem.

A rw tmpfs + ro jffs2 union is not exactly the basis for a 'usable'
system.  I merely meant to suggest that this was an additional benefit
to this scheme that might be useful to users in some situation.


> the idea is intriguing, but it would have to be a limited mode
> of operation:  i.e., no activity startup, please reboot soon.

Agreed.

Erik