Active Topics
-
Firefox with Leste (10)
to Maemo 7 / Leste by teroyk - 3 days, 9 hrs ago - more...
|
2010-12-06
, 15:15
|
|
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
"Impossible is not in the Maemo vocabulary" - Caballero
|
|
2010-12-06
, 15:39
|
|
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: | ||
 |
|
2010-12-06
, 15:42
|
|
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).
- 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).
|
|
2010-12-06
, 15:48
|
|
Posts: 692 |
Thanked: 264 times |
Joined on Dec 2009
|
#5
|
Originally Posted by Rob1n
Yeah I think this is what happened, the browserd process must have been using the files.
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.
__________________
"Impossible is not in the Maemo vocabulary" - Caballero
"Impossible is not in the Maemo vocabulary" - Caballero
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