Thursday, May 17, 2012

'Low Space' on Samsung Galaxy S

Using CyanogenMod 9 Android ROM on Samsung Galaxy S, lately I ran more often into the "Low space on device" message. The message was a bit confusing for an ordinary user because all the logical components were mostly empty. Those standard ones were:
  1. phone memory
  2. internal SD card
  3. external SD card
However, the things are a bit trickier than they seem at first glance. The devs of CyanogenMod used fast memory component in the phone to store application data (databases and configuration files mostly) onto it, effectively improving the system performance because reading these files was now much faster than on stock Samsung ROM. The stock ROM simply used the internal phone memory (2GB in size) to store all these files. In comparison to CM9 such a system would run extremely slow.
The drawback to the above approach is that the fast partition, where /datadata is stored, is only 170MB in size. Quite a few applications do not pay much attention where and how they store their files so this partition fills up pretty quickly. At first it was quite difficult to even understand how to see what has filled up. You can check the size and free space by using DiskUsage application and selecting /datadata as the location to be analyzed.
Some people recommended moving applications to SD card. This, however, does not solve anything in this case because it moves files from internal phone's 2GB partition to the SD card. But my 2GB partition was already 80% empty. Not knowing what was going on initially, I even used Titanium Backup to move some system applications to SD card. What a waste of effort.
The background information was scattered in different forum posts. A very useful one is here. That one contains a script that, if run on boot, would move all the files from /datadata to /data/data (from 170MB partition to 2GB partition) and then moves only the files that are *both* read and written into, back onto the fast /datadata partition. It creates symbolic links on the slow partition to these configuration files and databases, improving their performance. The /data location (being on 2GB partition) has good-enough read performance so libraries and other static files that are moved to /data/data still perform well.
This would be a great solution, only if it worked. I flashed the package into my Galaxy S, rebooted phone a few times but found out that /data/data was still a symbolic link to /datadata and all the files were still on the /datadata partition. As a result of running the script, /data/data was supposed to be converted to a real directory, with only the 'database' and a few other directories moved to /datadata. However, this was not the case.
So, knowing enough background information, and being encouraged to take things into my own hands by this post, I used Root Explorer to solve the problem:
  1. create /data/data_alen directory on 2GB partition,
  2. manually move iGo's whole directory (com.navngo.igo.javaclient) to /data/data_alen
  3. create symlink to com.navngo.igo.javaclient in /datadata
This was the simplest workaround that removed about 20MB from /datadata, freeing enough space for system to run for some time in the future. The apps that are clogging the system the most are browsers Google Chrome and Mozilla Firefox Aurora, with their cache. However, since I'm using these for testing and often, I prefer to keep them on the fast partition. Less used space hogs, like Google+ can, like iGo, be completely moved to /data partition.

Edit 2012-07-24: After installing new CyanogenMod, the applications for which the data was moved to a different partition would force-close. I tried a few things, like restoring the data with Titanium Backup and moving it back-and-forth with Total Commander, but that did not work. What worked was reinstalling the application (or restoring the data with Titanium Backup) and moving the data to the large partition and creating symlink to it with Root Explorer.
I haven't experimented much since this seems to work. The "low space" is handled for the moment. When it comes back I'll post back the findings of further experiments.

No comments: