Active Topics

 


Reply
Thread Tools
Posts: 692 | Thanked: 264 times | Joined on Dec 2009
#1
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!?
__________________
"Impossible is not in the Maemo vocabulary" - Caballero
 
Posts: 692 | Thanked: 264 times | Joined on Dec 2009
#2
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...
__________________
"Impossible is not in the Maemo vocabulary" - Caballero
 
Posts: 3,617 | Thanked: 2,412 times | Joined on Nov 2009 @ Cambridge, UK
#3
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.
 

The Following 2 Users Say Thank You to Rob1n For This Useful Post:
javispedro's Avatar
Posts: 2,355 | Thanked: 5,249 times | Joined on Jan 2009 @ Barcelona
#4
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).
 
Posts: 692 | Thanked: 264 times | Joined on Dec 2009
#5
Originally Posted by Rob1n View Post
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.
__________________
"Impossible is not in the Maemo vocabulary" - Caballero
 
Reply

Tags
rootfs


 
Forum Jump


All times are GMT. The time now is 13:40.