NAND out of space crash

Greg Smith gregsmitholpc at
Mon Jul 21 11:55:52 EDT 2008

Hi All,

I found which looks like a good place 
to track this problem.

I marked it blocker for 8.2.0.

Here's what I think we need:
- Sugar GUI always starts, no matter how much space is free on the NAND.
- If Sugar starts and you are low on space (exact size tbd) then we 
should alert the user to start clearing space in the journal.

I think Eben will work on the second part. Can someone solve the first 

Suggested steps would be to propose a solution, get buy in, code it and 
check it in.

I shouldn't have mentioned partitioning :-( All I meant was that we 
cannot solve this on upgrade by whacking all user data.


Greg S

> Date: Sat, 19 Jul 2008 12:39:04 -0400
> From: Erik Garrison <erik at>
> Subject: Re: NAND out of space crash (was Display warnings in sugar
> 	(Emiliano Pastorino))
> To: greg at
> Cc: devel at
> Message-ID: <20080719163904.GS9041 at eggs>
> Content-Type: text/plain; charset=us-ascii
> On Sat, Jul 19, 2008 at 11:47:21AM -0400, Greg Smith wrote:
>> Hi All,
>> Emiliano has an elegant workaround but crashing the XO on NAND full (to 
>> un-recoverable state?) is a heinous bug that affects essentially all users.
>> If someone has the bug ID handy can you send it out and mark it a 
>> blocker for 8.2.0 (priority = blocker and keyword includes blocks:8.2.0)?
>> Can I get a design proposal (no re-partitioning please!), scoping and 
>> lead engineer on it ASAP?
>> If you have to stop working on something else to do this, let me know 
>> what will drop and I'll help weigh the consequences.
> My impression is that the long-term benefits of partitioning mean that
> it's worthwhile to devote effort to it.  Are we not going to work on
> partitioning in the future?
> In addition to a more solid solution to the NAND fillup issue, we get
> the opportunity to improve system performance and upgrade procedures.
> Partitioning will allow us to test out LZO data compression for the XO's
> filesystems (excluding /boot and /security).  We would expect a
> significant i/o performance boost from the use of LZO.  Additionally,
> partitioning would improve OFW-level system updates (e.g. copy-nand) by
> making it far simpler for the update procedure to leave user data
> intact.
> That said there are obviously a lot of troubles with partitioning.
> Updating an existing system to a partitioned one without mashing user
> data is a major issue.
> Erik

More information about the Devel mailing list