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/ ) _______________________________________________ Devel mailing list [email protected] http://lists.laptop.org/listinfo/devel
