NAND Flash

Fillup problem seen in Uruguay

Possible solutions:

Prior to fillup and at first boot during fillup:

• Write a large file to disk during system upgrade. Check during boot if the filesystem is close to full, and if so, delete this file (so that we can continue to boot), and set a flag in the filesystem indicating the system state.
• Check at boot if the filesystem is close to full. If so, use unionfs to mount a tmpfs+jffs2 overlay such that applications can write to the root filesystem as needed. Set a flag in the filesystem indicating the system state.
• Remove all file writes from the boot sequence such that we can boot into Sugar and run the journal (to delete files). (This has been done with patches to olpc-session and our X configuration files, and needs to be tested).

We run a check in /usr/bin/olpc-session if the flag (e.g. /etc/nand-almost-full-warning) is set and launch a recovery system instead of the typical Sugar shell. This system could be X running a single client application. Ideally this appears to users exactly as the Journal, only with a warning (and possibly change of color scheme) noting that users must delete some files from their journal or they will be unable to (re)boot into a normal session. As users delete a sufficient amount of data to fall back below the threshold we indicate that we can reboot, and allow them to if they desire.

After fillup has been resolved:

• If we are using the file solution, we must reinstate the space-filler file at reboot.