[Techteam] NAND full issue

[Mitch Bradley]

Martin Langhoff wrote:
> On Sat, Jul 26, 2008 at 1:00 PM, Daniel Drake <dsd at laptop.org> wrote:
>   
>> unionfs will involve a kernel change.
>>     
>
> Erik's got a ko to add to the initrd AIUI.
>
>   
>> Have we considered sorting by date and removing from oldest to new until
>> the threshold is reached? Perhaps excluding starred items.
>>     
>
> Both date and size are flawed -- Greg and Cjb have explored the flaws
> of both approaches on devel at . The best notes on this are from Mitch so
> far - he looked at the FSs and spotted things we can safely delete.
> And we cannot query for starred items without starting the journal,
> which does not start in no-space conditions.
>
> IMHO, Cjb's script should delete caches and the files various files we
> know are safe to nuke _before_ we even consider user data
>   

The big-ticket item is the contents of ~/.sugar/data .  According to 
Tomeu in the attached
message, those files are leaks and could be deleted on boot without 
further ado.

In the images that I analyzed, those files represented 50% or more of 
the size of /home,
ranging from ~500 to ~800 MB.  As a "quick fix", just deleting those 
leak files on every
boot would probably reduce the incidence of NAND-full reboot failures by 
two orders
of magnitude, which should be enough to downgrade the problem from 
"critical" to
"minor annoyance".

Ironically, the presence of that leak (which Tomeu claims is fixed in 
Update.1) may
inoculate the system against NAND fillup from other causes, by 
"reserving" space that
can be reclaimed upon reboot.

That suggests a long-term safety strategy:

a) Determine how much free space is needed to ensure that the system can 
boot up
to a level where filesystem cleanup and maintenance can be performed.  
For example,
let's say the magic amount is 50 MB.

b) Add a 50 MB space-holder file to the filesystem on the first boot (or 
as part of the
initial image).  Fill it with incompressible data so it actually 
occupies the full space.

c) On each boot, if there is less than 50 MB free, delete the 
space-holder file to free
up space, and boot in maintenance mode so the user or a helper can clean 
up.  Continue
booting in maintenance mode until the free space has increased above 
some threshold.
After the cleanup, recreate a space-holder file.

Of course, it is still important to automate as much cleanup as can 
safely be performed
without user intervention, but the space-holder approach is still a good 
"backstop" to
avoid trips to a repair center.

>  - Mitch has identified stray CVS directories. These are safe to nuke.
>  - /var/cache/yum
>  - ~/.sugar/default/logs
>  - ~/.sugar/default/gecko/Cache
>  - Someone mentioned large support files in eToys.
>
> Might be worthwhile to nuke large Activities in ~/Activities.
>
> If not enough space is available, then it makes sense to nuke user data.
>
> cheers,
>
>
>
> m
>   

-------------- next part --------------
An embedded message was scrubbed...
From: "Tomeu Vizoso" <tomeu at tomeuvizoso.net>
Subject: Re: [Techteam] Files from Uruguay
Date: Thu, 24 Jul 2008 09:25:36 +0200
Size: 6815
URL: <http://lists.laptop.org/pipermail/devel/attachments/20080727/eeb935cf/attachment.mht>