Today I tried optifying /usr/lib/microb-engine. I moved it and symlinked it. This made the browser run at a crawl so I deleted the symlink and moved the directory back. The browser was back to normal. But suddenly I now had 20MB less free rootfs space
That can't be caused by the files being de-sparsed, that's almost the size of the files themselves! Why such a difference? When I look at the breakdown with Storage Usage I don't see anything different, but df-h confirms the loss of free space.
I'm going to restore my rootfs and /opt from a backup I made on Saturday, but still, WTF!?
update: just out of curiosity I rebooted (was on a record 15 days uptime and was going for more) and the space went back to what it was before. Weird...
Did you check whether the space had actually freed up after you originally moved the directory? The filesystem can't properly delete a file if it's still open (it deletes the directory entry, but the file data must be kept), so I'd guess the free space never actually dropped, and when you moved them back it had to create a new copy. A reboot would close the files and allow the deletion to complete, freeing up the space again.
I can see three reasons for this:
- Packages in the base image or installed via the application manager while doing a SSU are more compressed than the rest of files. (Same reason upgrading Maemo with apt-get instead of H-A-M uses slightly more space after the procedure). This however only accounts for a little %.
- UBIFS might have troubles calculating free space until a GC run or a reboot. JFFS2 at least had.
- There's a browserd process that keeps the microb files in use. This means that even if you unlink (delete) them, they will be kept in the disk as long as the browserd process keeps using them. Even if you overwrite the file names with another set of files, the original file contents will remain on disk until browserd dies (and of course, browserd died when you rebooted).
Did you check whether the space had actually freed up after you originally moved the directory? The filesystem can't properly delete a file if it's still open (it deletes the directory entry, but the file data must be kept), so I'd guess the free space never actually dropped, and when you moved them back it had to create a new copy. A reboot would close the files and allow the deletion to complete, freeing up the space again.
Yeah I think this is what happened, the browserd process must have been using the files.
