[Sugar-devel] [PATCH Browse] Cancel a download if space is very tight SL #394

[Martin Langhoff]

On Tue, Sep 11, 2012 at 9:07 PM, Manuel Kaufmann <humitos at gmail.com> wrote:
> This is what I got:
>
> [olpc at xo-07-30-50 ~]$ mkdir /tmp/foo
> [olpc at xo-07-30-50 ~]$ sudo mount -t tmpfs -o size=1M none /tmp/foo
> [olpc at xo-07-30-50 ~]$ python
> Python 2.7.3 (default, Apr 30 2012, 23:07:00)
> [GCC 4.7.0 20120416 (Red Hat 4.7.0-2)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>>>> f = open('/tmp/foo/cooool.txt', 'w')
>>>> f.write('w' * 200 ** 2)
> (...)
>>>> f.write('w' * 20000000)
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> IOError: [Errno 28] No space left on device

I guess that's what we'll want to grep for in the sugar datastore code ;-)

Hmmm, reading the code in download.py. AIUI Browse lets webkit run the
downloading (I cannot see any write() calls around). When we say

        self._download.set_destination_uri('file://' + self._dest_path)
        self._download.start()

we pass the ball to webkit. So in this case, we most of the writing is
being done in webkit. I do wonder what happens if webkit gets ENOSPC.
Does it manage to report it to Browse? Does it cleanup the partial
tmpfile? If not, should we file a bug upstream?

Also, IIRC, when you give a file to the datastore, the datastore does
not make a copy. It should make a hardlink to it. I hope the current
datastore is still sane in that regard. Still, if you are extremely
tight for space the datastore saves metadata, which could hit ENOSPC.

So I see 3 places where we could run out of space

 - Empty tmpfile setup, extremely unlikely; you may want to implement
a try/except for consistency and elegance and good karma...

 - During the webkit download -- most probable stage where you'll hit
it. How does Webkit behave? Does Browse need to do anything?

 - During datastore.write() -- I truly believe that the
datastore.write() call doesn't literally make a copy of the file --
should just create/update the hardlink and associated metadata
(including progress bar). It is not very likely that we'll run out of
space during this call, but it should be handled, I believe.

Does that make sense? TBH, my datastore knowledge is extremely rusty.
It has been a long time...



m
-- 
 martin.langhoff at gmail.com
 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