NAND full issue

[Daniel Drake]

Kimberley Quirk wrote:
> OLPC's response is "Failsafe" for 656, per703, and 8.1.2; and a formal  
> bug fix for 8.2 going forward:

> Uruguay:
> Erik is working with Uruguay on the solution described as "Union  
> Mount" below. It is important that Uruguay own this bug fix themselves  
> and can maintain it as needed, test it to their satisfaction, decide  
> how to distribute it. This can be delivered as a USB or wireless  
> download. Uruguay also has the choice to use the options supported by  
> OLPC above.

So unionfs is the "formal bug fix for 8.2 going forward", or is it a 
Uruguay-specific thing?

unionfs will involve a kernel change. Are we planning to shift them from 
2.6.22 to 2.6.25 where unionfs has been included, or are we going to 
backport unionfs to 2.6.22?

Also, I am a little wary of unionfs, I have used it in the past and 
found it to be buggy and unreliable. It may be better now, but we should 
be cautious.

> RECOVERY SOLUTIONS -
> Automatic Free Space:
> Provide USB bootable build that would free space in some way. Can we  
> identify a class of things that we know can be deleted (like cracklib  
> dictionary of unsafe passwords, large activities). Add a note that a  
> delete is going to happen during boot.

Only works the first time they fill it up, obviously.

> Failsafe:
> Can be inserted in the build, include 'automatic free space'. It opens  
> the datastore and sorts by size, wants to find 50M, pops off the stack  
> deleting stuff from largest to smallest. Can it explain afterwards  
> what it has done or explain ahead of time what it might do. Provide  
> options for what to delete.

Have we considered sorting by date and removing from oldest to new until 
the threshold is reached? Perhaps excluding starred items.

> The Fix: (fix to 7587)
> When the NAND is full, Sugar will boot but not be allowed to write. A  
> notification about space and inability to write needs to be displayed.

...and the space can be freed by deleting activities and journal items?
No unionfs involved?

I feel that is the best way forward.

Daniel