[Sugar-devel] Not enough space adventure

[Martin Langhoff]

On Tue, Sep 18, 2012 at 8:42 AM, Manuel Kaufmann <humitos at gmail.com> wrote:
> We where discussing about this last week[1] and we found the "root"
> issue of this problem: Sugar is not handling ENOSPC error. This could
> cause some problems at boot time when the XO is restarted, but as we
> discussed[2], Linux has made some improvement on this side and it
> seems that it recovers without problem (we need more testing here, I
> think).

Thanks for diving into this!

> So, there are different problems to manage here:
>  1. What are we going to do when ENOSPC is reached?

I did some work lastweek, and plan to hack on it tomorrow.

>  2. How are we going to avoid ENOSCP?
...

>  - remove the annoying check of free space

I hope that's not completely removed (I see Gonzalo's email...). It is
not very effective preventing you from using activities, but it does
prompt users to do something (remove stuff?).

BTW, 50MB may be too high, some units with 2GB storage, installing
modern builds, end up with 150MB free total :-/

>  - create a signal inside sugar-toolkit-gtk3 datastore that is emitted
> when free space is behind
> "sugar3.datastore.datastore.SPACE_THRESHOLD". This check is done every
> time a model is updated or created by the datastore.

A model? Maybe my lingo is a bit stale... a datastore entry you mean?

>  - this signal can be connected from every activity that wants to
> handle this situation. For example in Browse we are cancelling the
> download in progress when we get that signal

So there is a bit of confusion here...

 - When we start the download, if we get Content-Length, we compare it
with disk space available, or with disk space available minus
datastore.SPACE_THRESHOLD?

 - Related: can we ask the datastore to tell us its SPACE_THRESHOLD,
so we don't hardcode it? Ah, I see you have a helper function.

Personally, I would prefer to preserve a relatively high threshold
(lower than 50MB, but say, 10MB) for the _warnings_. But still allow a
download to complete. I would only cancel a download in Browse if will
leave us with <1MB disk space.

To put it in other words, we are investing too much effort in...
warnings. And we are mixing a high threshold that is good for a
warning, with something that disrupts an operation (cancel download).
You may be downloading an activity that allows you to delete stuff :-)

Finally, we seem to be missing the tmpfile cleanup related to
incomplete downloads. That can invisibly "eat" a ton of disk space in
a way that the end user cannot cleanup...

cheers,



m
-- 
 martin at laptop.org -- Software Architect - OLPC
 - ask interesting questions
 - don't get distracted with shiny stuff  - working code first
 - http://wiki.laptop.org/go/User:Martinlanghoff