Comment 1 Andre Klapper 2009-10-16 03:45:41 UTC

I ran into a similar issue at Mameo Summit after installing lots of apps.
Every two minutes I got an annoying ""Device storage memory full. Remove data
to free memory"" (or something similar) popup.
"df -h" stated that I have 0% space left on rootfs.

Comment 2 Andre Klapper 2009-10-20 20:09:26 UTC

Also see bug 5613.

Comment 3 Andre Klapper 2009-10-20 20:09:33 UTC

*** Bug 5613 has been marked as a duplicate of this bug. ***

1. Started with several MB free on / (didn't grab the exact figure), then
installed a few small packages:

Filesystem           1k-blocks      Used Available Use% Mounted on
rootfs                  233224    229892         0 100% /

2. After reboot:
rootfs                  233224    202200     26744  88% /

3. After installing tuner (nominally a 24K package!):
rootfs                  233224    205816     23128  90% /

One thing that tuner's (and most packages') post-install script does is update
the gtk icon cache.  This is stored on the rootfs and is currently 20MB
(although highly compressible) here.

4. So, let's just update the cache manually and see what happens:

Nokia-N900-41-10:~# gtk-update-icon-cache -f /usr/share/icons/hicolor/
gtk-update-icon-cache: Cache file created successfully.
Nokia-N900-41-10:~# df /
Filesystem           1k-blocks      Used Available Use% Mounted on
rootfs                  233224    224400      4540  98% /

Ok, that's bad but let's sync the fs to reclaim some:

Nokia-N900-41-10:~# sync
Nokia-N900-41-10:~# df /
Filesystem           1k-blocks      Used Available Use% Mounted on
rootfs                  233224    209352     19588  91% /

Better, but that's 3.5MB gone since step 3.  Maybe something is keeping the old
version open, let's find out:

Nokia-N900-41-10:~# ls -i /usr/share/icons/hicolor/icon-theme.cache 
  80519 /usr/share/icons/hicolor/icon-theme.cache
Nokia-N900-41-10:~# gtk-update-icon-cache -f /usr/share/icons/hicolor/
gtk-update-icon-cache: Cache file created successfully.
Nokia-N900-41-10:~# sync
Nokia-N900-41-10:~# df /
Filesystem           1k-blocks      Used Available Use% Mounted on
rootfs                  233224    212912     16028  93% /
Nokia-N900-41-10:~# lsof | grep 80519
Nokia-N900-41-10:~# lsof | grep deleted
hildon-de 1770       user   20w   REG       0,12        0      17665
/tmp/mb_wm_theme_loading (deleted)

Nope, but another 3.5MB has leaked just like that.

Perhaps I'm overlooking something, but it looks like a UBIFS problem to me. 
Maybe it's a leak or maybe it's just too pessimistic in its free space
reporting, but is there any way to trigger its garbage collection without a
reboot?  I tried remounting / read-only but it fails:

Nokia-N900-41-10:~# mount -n -o ro,remount /
mount: mounting ubi0:rootfs on / failed: Device or resource busy

Another reboot recovers the "lost" space of course:
Nokia-N900-41-10:~# df /
Filesystem           1k-blocks      Used Available Use% Mounted on
rootfs                  233224    202292     26648  88% /

Comment 5 Andre Klapper 2009-10-30 11:07:13 UTC

Great & helpful analysis, Lucas! Thanks.

Comment 6 Eero Tamminen 2009-10-30 15:07:38 UTC

(In reply to comment #4)
> Perhaps I'm overlooking something, but it looks like a UBIFS problem to me. 
> Maybe it's a leak or maybe it's just too pessimistic in its free space
> reporting, but is there any way to trigger its garbage collection without a
> reboot? 

Sync initiates GC.

However, what gets you the disk space back is applications not anymore keeping
the old versions of the updated files open after reboot so that the file system
can actually GC them.

(In reply to comment #6)
> However, what gets you the disk space back is applications not anymore keeping
> the old versions of the updated files open after reboot so that the file system
> can actually GC them.

I did check with lsof (and even tried a "killall hildon-desktop" which I
probably should have mentioned).  Is there anything else I can test?

Comment 8 Eero Tamminen 2009-10-30 16:25:29 UTC

(In reply to comment #7)
> I did check with lsof (and even tried a "killall hildon-desktop" which I
> probably should have mentioned).  Is there anything else I can test?

If you check which processes have this file open:
  lsof | grep /usr/share/icons/hicolor/icon-theme.cache

before and after the package installation, you see that the inode has changed
for the cache file these processes keep open.

However, if you "strace -f -p PID" these same processes when you do the new
application install, you'll see that they didn't close and re-open this file. 
Therefore kernel needs to keep the old file contents for them.

(In reply to comment #8)
> If you check which processes have this file open:
>   lsof | grep /usr/share/icons/hicolor/icon-theme.cache
> 
> before and after the package installation, you see that the inode has changed
> for the cache file these processes keep open.

Right, so lsof lies :-(  Oh well, should probably file a bug about that
somewhere...

However "grep /usr/share/icons/hicolor/icon-theme.cache /proc/[1-9]*/maps" does
show the correct (old) inode.  So it's not UBIFS (sorry!) which is /very/ good
news.  

So the scenario AIUI is:
1. Device boots, processes start and mmap the existing icon cache.
2. User installs app.
2. Package post-install script updates icon cache.
3. Pre-existing processes still hold the old version(s) open, while any apps
started after this point use the new one. 3.5MB down the drain.
4. User installs another app.
5. Goto 2.

I guess it's unrealistic to expect all offending packages to be fixed soon, but
perhaps moving the icon cache off the root filesystem is an option?

@Andre: is there anything relevant in bugzilla.gnome.org that might be useful
here?

(In reply to comment #9)
> I guess it's unrealistic to expect all offending packages to be fixed soon, but
> perhaps moving the icon cache off the root filesystem is an option?
While on this topic, I would also like to mention locale cache (about 16MB of
data in a single file) that may also be worth moving off rootfs.

Some updates:

- Newer lsof versions (tested 4.78) display the inodes of deleted mmaped files
correctly, eg:

worldcloc 1723       user  mem       REG      254,1               81009
/usr/share/icons/hicolor/icon-theme.cache (path inode=84452)
worldcloc 1723       user  mem       REG      254,1 20833088      84452
/usr/share/icons/hicolor/icon-theme.cache

- After installing 5 updates in one go with application manager, there are now
6 different versions of the icon cache in use and available space dropped from
25936 to 6684 blocks.

- More importantly, running 'lsof|grep "path inode="' and 'lsof|grep
"DEL"|egrep -v "/dev/zero|SYSV00"' shows no other deleted files still in use.

- The gtk icon cache issue is also reproducible in scratchbox, so it looks like
the problem is 100% userland.

- In GNOME 2.26 (Ubuntu 9.04 to be precise) rebuilding the icon cache and using
it (eg by opening a new gtk application) causes all running processes to
release the old version and open the new one.

It seems solvable, but at this point it's very unfamiliar territory to me.  Are
there any GTK+ hackers around that can shed some light?

(In reply to comment #11)
> - More importantly, running 'lsof|grep "path inode="' and 'lsof|grep
> "DEL"|egrep -v "/dev/zero|SYSV00"' shows no other deleted files still in use.

I should add: "lsof|grep deleted" shows only /tmp/mb_wm_theme_loading.

Comment 13 Eero Tamminen 2009-11-02 10:38:45 UTC

(In reply to comment #11)
> - Newer lsof versions (tested 4.78) display the inodes of deleted mmaped files
> correctly, eg:
> 
> worldcloc 1723       user  mem       REG      254,1               81009
> /usr/share/icons/hicolor/icon-theme.cache (path inode=84452)
> worldcloc 1723       user  mem       REG      254,1 20833088      84452
> /usr/share/icons/hicolor/icon-theme.cache
> 
> - After installing 5 updates in one go with application manager, there are now
> 6 different versions of the icon cache in use and available space dropped from
> 25936 to 6684 blocks.

The think I don't understand is how there can be so many different versions of
the icon cache if one just installs multiple applications in AM without
starting other applications.

I would understand there being two versions, the original, and the latest one. 
What process keeps the intermediate versions?

Comment 14 Eero Tamminen 2009-11-02 11:01:13 UTC

(In reply to comment #10)
>> I guess it's unrealistic to expect all offending packages to be fixed soon,
>> but perhaps moving the icon cache off the root filesystem is an option?
>
> While on this topic, I would also like to mention locale cache (about 16MB of
> data in a single file) that may also be worth moving off rootfs.

locale-archive could be used by things that are run before /home is mounted.  

If I read the startup scripts correctly, currently it seems to be mounted in:
---- /etc/event.d/rcS-late ---
...
start on started xomap
...
script
...
    /bin/mount /home || echo "Failed to mount /home partition."
------------------------------


Btw. This shows what sized files are opened, sorted by file size:
  lsof | egrep -v '(DEL|/dev/|unix|sock|pipe)' | \
    awk '{if($7>0) print $7, $9}' | sort -n | uniq

...
815172 /usr/lib/libdb-4.2.so
825344 /home/user/.cache/tracker/file-meta.db
828660 /usr/lib/libstdc++.so.6.0.9
846784 /usr/lib/libtelepathy-glib.so.0.30.0
867344 /usr/lib/libglib-2.0.so.0.2000.3
911512 /usr/lib/microb-engine/libmozjs.so
940144 /usr/lib/microb-engine/libnss3.so
944144 /usr/lib/libX11.so.6.2.0
984884 /usr/bin/modest.launch
1011520 /usr/lib/libcalendar_backend.so.0.0.0
1145180 /usr/lib/libsync4j.so.3.0.0
1160576 /lib/libc-2.5.so
1172896 /usr/lib/libxml2.so.2.6.32
1229276 /usr/lib/libcrypto.so.0.9.8
1334008 /usr/lib/libglslcompiler.so
1525356 /usr/bin/Xorg
1779664 /usr/bin/intellisyncd
1780247 /var/log/syslog
3607964 /usr/lib/libgtk-x11-2.0.so.0.1400.7
6850580 /usr/lib/browser/plugins/libflashplayer.so
13315848 /usr/lib/microb-engine/libxul.so
16510624 /usr/lib/locale/locale-archive
20306412 /usr/share/icons/hicolor/icon-theme.cache

(As only one copy of the previous file needs to be retained by kernel / file
system, it doesn't matter how many processes are keeping the old version open,
as long there's at least one process which isn't restarted on these new package
installs.)


Because rootfs content is LZO compressed, what matters for the rootfs usage is
the file size as compressed.  For above files this:
for file in $(lsof | egrep -v '(DEL|/dev/|unix|sock|pipe|/$)' | awk \
 '{if($7>0) print $7, $9}' | sort -n | uniq | tail -20 | awk '{print $2}'); do
    lzop -c $file > ${file##*/}.lzo
done
du -ks *.lzo | sort -n

gives:
...
512     libglib-2.0.so.0.2000.3.lzo
512     libnss3.so.lzo
576     libcalendar_backend.so.0.0.0.lzo
576     libmozjs.so.lzo
576     modest.launch.lzo
640     libX11.so.6.2.0.lzo
640     libsync4j.so.3.0.0.lzo
704     libc-2.5.so.lzo
704     libxml2.so.2.6.32.lzo
768     libcrypto.so.0.9.8.lzo
832     libglslcompiler.so.lzo
960     intellisyncd.lzo
1024    Xorg.lzo
2048    libgtk-x11-2.0.so.0.1400.7.lzo
2624    icon-theme.cache.lzo
3648    libflashplayer.so.lzo
6272    locale-archive.lzo
7360    libxul.so.lzo

From here one can see that in addition to locale-archive e.g. Browser related
libraries (especially Flashplayer and XUL library) are huge.

For RAM usage the uncompressed size is more important, but one needs to use
sp-smaps-* tools to see how much of that data applications actually need in
RAM.


AFAIK SSU closes down all applications before proceeding, including pre-started
ones like Browser, but I'm not sure whether it closes down all Browser
daemon(s).  If not, currently user may need to uninstall stuff enough that she
gets >10MB more (compressed) space on the root file system free before
proceeding.


Locale-archive is used also by other things than apps and Gtk is used by
application manager itself so we cannot really avoid that by closing down
processes.

As SSU reboots the device at the end and we test how much free space there
needs to be for SSU update (+ add some safe margin), it should not fail.  It's
just currently done non-optimally.  I.e. only application installations after
SSU should be an issue...

Comment 15 Marius Vollmer 2009-11-02 14:47:31 UTC

(In reply to comment #14)
> locale-archive could be used by things that are run before /home is mounted.  

Because of the very special situation that Maemo 5 is in, I think we can make
the argument that /home should be mounted as early as needed: together with
/usr, say, and both could be mounted as  soon as the needed kernel modules can
be loaded.

Comment 16 Eero Tamminen 2009-11-02 15:00:15 UTC

(In reply to comment #13)
> What process keeps the intermediate versions?

Would seem to be hildon-home (easy to see just by monitoring its VmSize, it
increases ~20MB on each app install).  Next question is, is it home itself or
one of the applets...


(In reply to comment #15)
> Because of the very special situation that Maemo 5 is in, I think we can make
> the argument that /home should be mounted as early as needed: together with
> /usr, say, and both could be mounted as  soon as the needed kernel modules can
> be loaded.

Because Browser stuff is larger than locale archive, first I would be more
interested to know whether AM terminates Browser daemon (master, rtcom, browser
UI) instances before doing SSU?

Comment 17 Marius Vollmer 2009-11-02 15:41:06 UTC

(In reply to comment #16)

> Because Browser stuff is larger than locale archive, first I would be more
> interested to know whether AM terminates Browser daemon (master, rtcom, browser
> UI) instances before doing SSU?

Not as far as I know.  It closes all applications, but does nothing special for
daemons.

(In reply to comment #16)
> (In reply to comment #13)
> > What process keeps the intermediate versions?
> 
> Would seem to be hildon-home (easy to see just by monitoring its VmSize, it
> increases ~20MB on each app install).  Next question is, is it home itself or
> one of the applets...

The application menu (the one that opens when you click in the upper left
corner) reloads the list after an app installation, and as it displays icons of
applications, it most likely uses the icon cache for that. Maybe that's
something that is fixable in the code of that application?

(In reply to comment #18)
> (In reply to comment #16)
> > (In reply to comment #13)
> > > What process keeps the intermediate versions?
> > 
> > Would seem to be hildon-home (easy to see just by monitoring its VmSize, it
> > increases ~20MB on each app install).  Next question is, is it home itself or
> > one of the applets...
> 
> The application menu (the one that opens when you click in the upper left
> corner) reloads the list after an app installation, and as it displays icons of
> applications, it most likely uses the icon cache for that. Maybe that's
> something that is fixable in the code of that application?

Oh, sorry, the application menu seems to be provided by hildon-desktop, not
hildon-home. (if you type "killall hildon-desktop" into the xterm and then
quickly open the application menu, you can see how the icons get loaded there)

Hildon-home might still use the icon cache, as all the launcher icons have to
display application icons which - again - probably is done using the icon cache
file.

Comment 20 Eero Tamminen 2009-11-02 17:04:51 UTC

Created an attachment (id=1528) [details]
Script to count how many times processes mmap given file

(In reply to comment #19)
> Hildon-home might still use the icon cache, as all the launcher icons have
> to display application icons which - again - probably is done using the icon
> cache file.

Good point, I forgot about that.  So the installed application icons can
actually be used by two processes (and their memory shared by the icon cache).


Attached is a script counting how many times and which processes map the given
file (One could get almost same info from lsof, but it doesn't seem to give
full process names and it misses process mmapping the same file twice).

After bootup once all the pre-started apps have started and opening Application
manager, the result is on my device:
1 browser [1858]
1 browserd [1852]
1 hildon-application-manager [2205]
1 hildon-desktop [1083]
1 hildon-home [1082]
1 hildon-status-menu [1076]
1 image-viewer [1884]
1 modest [1895]
1 osso-addressbook [1841]
1 rtcom-call-ui [1845]
1 rtcom-messaging-ui [1850]

To see which applications can cause this issue on install and which also on
uninstall, use:
grep  gtk-update-icon-cache /var/lib/dpkg/info/*.post*

After uninstalling one such app:
1 browserd [1852]
1 camera-ui [1112]
1 hildon-desktop [1083]
1 osso-addressbook [1841]
1 systemui [974]
2 browser [1858]
2 hildon-application-manager [2205]
2 hildon-home [1082]
2 hildon-status-menu [1076]
2 image-viewer [1884]
2 modest [1895]
2 rtcom-call-ui [1845]
2 rtcom-messaging-ui [1850]

And then after installing few apps:
1 browserd [1852]
1 camera-ui [1112]
1 hildon-desktop [1083]
1 osso-addressbook [1841]
1 systemui [974]
2 browser [1858]
2 hildon-status-menu [1076]
2 image-viewer [1884]
2 modest [1895]
2 rtcom-call-ui [1845]
2 rtcom-messaging-ui [1850]
2 worldclock [2520]
3 hildon-application-manager [2205]
5 hildon-home [1082]

At this point hildon-home or one of its applets had managed to map one
icon-theme.cache instance twice, but as you see, AM isn't completely innocent
either.


Btw. After installing all these apps/applets, I noticed that some of the Home
applets I had installed from extras cause Home window to be updated at 10Hz(!)
even when Home is on background.  (I wondered why Home was using CPU while AM
was on top and "xresponse -a '*' -w 0" told the rest.  If somebody's using
these applets from extras, please check which one of them are this broken and
file bugs against them.)

Comment 21 Andre Klapper 2009-11-06 14:21:54 UTC

So, way worse for me here. Wondering if this is the same issue?:

SOFTWARE VERSION:
45-14

ADDITIONAL SOFTWARE ALREADY INSTALLED:
openttd, rootsh

STEPS TO REPRODUCE:
1. Become root in Terminal ("sudo gainroot")
2. Run "df -h" and get:
    Filesystem Size   Used    Available Use%
    rootfs     227.9M 151.3MB 72.4M     68%
3. run the command 
   "apt-get install ukeyboard xournal maelstrom maemo-recorder hildon-systray 
    tomotko touchsearch kmplayer personal-photo-frame openntpd madbomber 
    stockthis wormux"
4. Get the message:
   "Need to get 69,4 MB of archives.
    After this operation, 117MB of additional disk space will be used.
    Do you want to continue [Y/n]?"
5. Do not realize that 117MB > 72.4MB and press "y" and "Enter" key.
6. Wait while device installs stuff.
7. After some time, get
   "dpkg: Unrecoverable fatal error, aborting:
    [...] No space left on device
    E: Sub-process /usr/bin/dkpg returned an error code (2)"
8. Oops. Try "apt-get remove" for one of the packages.
9. Get an error:
   "E: dpkg was interrupted, you must manually run 'dpkg --configure -a' 
    to correct the problem"
10. Hence run "dpkg --configure -a"
11. Get an error: 
    "dpkg: Unable to open/create status database lockfile: 
     No space left on device"
12. Start Application Manager.
13. Get "Operation failed" popup. 
14. Click "Uninstall".
15. Get "(no applications installed)".
16. Run "df -h" and get:
     Filesystem Size   Used    Available Use%
     rootfs     227.9M 227.9MB 0         100%

EXPECTED OUTCOME:
* In step 5 there should be a warning, or even better: The process should be
stopped.
* User should somehow be able to remove installed software to get free space
again.

ACTUAL OUTCOME:
User in a situation where he can only reflash the device if he does not get a
good idea, like "rm -rf /usr/share/themes/".
Rebooting does NOT help.

REPRODUCBILITY:
2 out of 2

>3. run the command 
>   "apt-get install ukeyboard xournal maelstrom maemo-recorder hildon-systray 
>    tomotko touchsearch kmplayer personal-photo-frame openntpd madbomber 
>    stockthis wormux"

That command alone will fill your rootfs because all deb are first downloaded
to /var/cache/apt/archives/, which is in rootfs unless something has changed

Try with application manager

Andre these are different issues.
If you re-install the same package several time, it'll exhaust rootfs due to a
bug in the icon cache handling.
This should not happen.

Your case is different as you tried to install more data than it is physically
available.

Aniello

Comment 24 Eero Tamminen 2009-11-06 17:56:45 UTC

(In reply to comment #21)
...
> 6. Wait while device installs stuff.
> 7. After some time, get
>    "dpkg: Unrecoverable fatal error, aborting:
>     [...] No space left on device
>     E: Sub-process /usr/bin/dkpg returned an error code (2)"
...
> 8. Oops. Try "apt-get remove" for one of the packages.
> 9. Get an error:
>    "E: dpkg was interrupted, you must manually run 'dpkg --configure -a' 
>     to correct the problem"
> 10. Hence run "dpkg --configure -a"
> 11. Get an error: 
>     "dpkg: Unable to open/create status database lockfile: 
>      No space left on device"

What was the package that failed at step 7?

dpkg should remove the failing package also in case when it fails due to
running out of space, but some packages can be buggy and write to disk stuff
that dpkg doesn't know about (and therefore cannot remove).


(In reply to comment #23)
> Your case is different as you tried to install more data than it is physically
> available.

Apt-get not warning about this seems stupid, but that's Debian issue, not Maemo
end user one.

The interesting question is does Application manager prevent / warn about this
case?

Comment 25 Andre Klapper 2009-12-01 17:07:14 UTC

This has been fixed in two packages and should be included in the internal
week43 build version.
(Note that 2009 is the year and the number after is the week.)

Any public update released with or after this build version will include the
fix.
Please verify that the new version fixes the bug by marking this bug report as
VERIFIED after the public update has been released and if you have some time.

*** Bug 7000 has been marked as a duplicate of this bug. ***

I simply linked archives directory, now it works in MyDocs to keep rootfs
alive.
Is it possible to move this directory to a larger storage in the future?
/var/cache/apt/archives/


(In reply to comment #22)
> >3. run the command 
> >   "apt-get install ukeyboard xournal maelstrom maemo-recorder hildon-systray 
> >    tomotko touchsearch kmplayer personal-photo-frame openntpd madbomber 
> >    stockthis wormux"
> 
> That command alone will fill your rootfs because all deb are first downloaded
> to /var/cache/apt/archives/, which is in rootfs unless something has changed
> 
> Try with application manager
>

I'm a bit weary to go into all the details, but before reflashing your device,
try this:

sudo ./flasher-3.5 --enable-rd-mode

And reboot.

Some info here:
http://www.freemoe.org/users/jebba/MALF/

And in bug #7019

sudo ./flasher-3.5 --enable-rd-mode

With this, I was able to recover my device *WITHOUT REFLASHING*. (It also
showed
that it wasn't a full / filesystem that kept my system from booting.)

Sorry for the noise, but I was prodded to add:

Note to children playing at home: DO NOT LEAVE YOUR SYSTEM IN R&D MODE. It will
cause weird side effects (such as making your keyboard flash), so you should
disable it. To disable it run:

sudo ./flasher-3.5 --disable-rd-mode

If you don't have sudo set up, just run the command as root. Note this is a
GNU/Linux command, I'm not sure about other OSes.

In sum: I had a bricked system, I put it in R&D mode, I booted up in R&D mode
fine, I then put the system in Production mode and booted up fine again without
the need for any reflashing or data loss.

Comment 30 Tim Samoff 2009-12-25 22:39:45 UTC

This appears to be FIXED in 2.2009.51-1, but leaving open in case others still
encounter it.

Comment 31 Tim Samoff 2009-12-25 22:40:51 UTC

(In reply to comment #30)
> ...but leaving open in case others still
> encounter it.
> 

Or, rather, leaving FIXED in case anyone needs to reopen it. ;)

Just to confirm I couldn't reproduce this bug in 51-1.

The fix seems to be doing away with icon caches altogether
(/usr/bin/gtk-update-icon-cache is now a nop shell script).  While this does
resolve the problem reported here I wonder if it's the final solution or a
temporary workaround and a better fix is coming in a later release.

Comment 34 Eero Tamminen 2009-12-30 16:03:20 UTC

(In reply to comment #33)
> The fix seems to be doing away with icon caches altogether
> (/usr/bin/gtk-update-icon-cache is now a nop shell script).  While this does
> resolve the problem reported here 

Disabling it speeds up application installation, decreases disk churn and frees
3MB(!) of disk space for other data.  If you don't reflash your device, you may
need to remove the cache file manually (I don't know whether SSU removes it).

As a downside it may slightly slows down some applications startup if they use
a lot of icons, especially such which data has already been loaded by other
apps.  Depending how icon data is laid out in the cache file, getting rid of it
may increase or decrease application real memory usage.  It will slightly
increase system RAM usage in general, but lower it at package installation
(less kernel page cache usage).  These differences should be too small to be
user visible though, so I think it's pretty good compromise.


> I wonder if it's the final solution or a temporary workaround and
> a better fix is coming in a later release.

AFAIK it's final, but not a complete solution.

For SSU there are further improvements:
* application manager disk space heuristics have been slightly improved
* application manager will kill more always resident processes on SSU so that
  they don't cause old disk contents (browser libs etc) to be retained
  until reboot
* UBIFS LZO compression level will be raised.  It was lower than what's used
  for the release images, so re-installing newer versions of pre-installed
  packages increased disk usage.

Higher compression level on rootfs means that more (compressable) data will fit
there, but SSU package installation will be slower.  (getting rid of icon cache
rewrite compensates for this on normal application installations, so I don't
think their speed changes significantly)

(In reply to comment #34)
> Depending how icon data is laid out in the cache file, getting rid of it
> may increase or decrease application real memory usage.  It will slightly
> increase system RAM usage in general, but lower it at package installation
> (less kernel page cache usage).  These differences should be too small to be
> user visible though

One advantage of the cache is that it's mmap'ed so it's shared between apps.  I
would expect higher memory usage overall, but to be honest I haven't noticed
any issues after using 2.2009.51-1 for a couple of days.

> so I think it's pretty good compromise.

Better than the previous situation for sure!  Still, I wonder how GNOME manages
not to run into this problem and whether it could be an easy fix in some
library, but life's too short to pursue further I guess.

> AFAIK it's final, but not a complete solution.

Ok, verifying then.  I had plenty of space left after flashing 2.2009.51-1 and
restoring all apps in one go, whereas I had to restore in several steps with
reboots inbetween with 1.2009.42-11.

(Also removing non-optified keyword as the solution didn't involve /opt after
all)

Comment 36 Eero Tamminen 2009-12-30 19:05:37 UTC

(In reply to comment #35)
> Still, I wonder how GNOME manages not to run into this problem

Desktop machines have typically GBs of free disk space, so you might not notice
an issue like this there...

If you're running your desktop machine with only few tens of MB of free space
and you start doing system upgrades, you're going to run into problems too. :-)

(In reply to comment #36)
> Desktop machines have typically GBs of free disk space, so you might not notice
> an issue like this there...

I meant that in GNOME 2.26 at least (comment 11) all running apps seem to
notice that the cache has changed and refresh it so there's no filesystem leak.

Comment 38 Andre Klapper 2010-01-14 12:26:45 UTC

The problem reported here should be fixed in the update released today for
public: The Maemo5 update version 2.2009.51-1 (also called "PR1.1" sometimes).
Please leave a comment if the problem is not fixed for you in this update
version.

Comment 39 Eero Tamminen 2010-01-14 15:41:31 UTC

(In reply to comment #38)
> The problem reported here should be fixed in the update released today for
> public: The Maemo5 update version 2.2009.51-1 (also called "PR1.1" sometimes).

It should be fixed already in the PR1.0.1 (44.1 update).

(In reply to comment #39)
> (In reply to comment #38)
> > The problem reported here should be fixed in the update released today for
> > public: The Maemo5 update version 2.2009.51-1 (also called "PR1.1" sometimes).
> 
> It should be fixed already in the PR1.0.1 (44.1 update).
> 

42-11: 14MB free
51-01: 16MB free

:-\

I run this script, after i have 55MB.
http://talk.maemo.org/showthread.php?t=40131&page=6

hey guys, i just encounter the no space available in installing apps after
installing hildon-input method-plugins-scim, hildon-theme-hitech,
hildon-theme-itheme & hitech.  i uninstalled some of the apps before hildon
apps but that aint work. after unstalling hildon apps my n900 was able to
download apps again and it run fast.

i need help for my themes. after i installed the pc suite for n900 so that i
can connect my phone to my pc the themes stop working.  when i tap the themes
in the phone settings it aint do nothing. now i cant change any themes even i
have downloaded few in application manager.

(In reply to comment #41)
> hey guys, i just encounter the no space available in installing apps after
> installing hildon-input method-plugins-scim, hildon-theme-hitech,
> ...
> i need help for my themes. after i installed the pc suite for n900 so that i
> can connect my phone to my pc ...
Your requests do not have anything to do with the bug tracker you are
commenting on. To get help from the community, post your questions to
talk.maemo.org. While doing that, keep in mind that none of the people
there are paid to solve your problems, so your success rate getting
help may vary.