For review: NAND out of space patch.

[C. Scott Ananian]

We should distinguish at least three solution spaces:
 a) UY's solution, based on a small patch to 656
 b) A solution to include in 8.2
 c) The "real" solution, in case there are limits to what we can do for 8.2.

cjb's patch is primarily for (a), with applications to (b) and
*perhaps* as a fail-safe for (c) (if we can detect the condition in
which the fail safe needs to be employed with any sort of
reliability).

For the record, I oppose the unionfs solution for the "real fix",
because it impairs overall reliability: it works for the "first boot
in completely full disk" case, but doesn't work for the "almost full"
case or for the "disk fills while I'm using sugar" case.  I prefer
making the core sugar APIs robust against write failures so that the
child can use the normal Sugar mechanisms to clean up and recover.
There are a number of components here: (trac #7125)
 1) we currently fail writing ~olpc/.boot_time (a debugging file)
 2) .Xauthority needs to be in a tmpfs (trac #317)
 3) sugar logging needs to ignore failures (logging failures shouldn't
crash the system!)
 4) the journal needs to be able to delete files even if zero space is
available.

Of these, (4) appears to be the most difficult.  A brief google search
on xapian.org turns up http://trac.xapian.org/ticket/241 which
indicates that the Xapian guys *believe* they've fixed database
operation with a full fs, but this probably requires some deep digging
and experimentation.  Tomeu has proposed an alternative: if sugar runs
and activities launch, we could have a separate "journal-like"
activity purely for cleaning up files, as an interim until the Journal
rearchitecture tentatively scheduled for 9.1.

At the moment, the plan seems to be to work on fixes for cases (a),
(b), and (c) in parallel, and take as much as we can for 8.2, subject
to release constraints.
  --scott
-- 
 ( http://cscott.net/ )