Root space - What is "optifying"? - Page 3 - maemo.org

Active Topics

Extra softwares in Sailfish using CLI, repositories, etc (117)
to SailfishOS by nieldk - 2 hrs, 20 mins ago
Firefox with Leste (6)
to Maemo 7 / Leste by teroyk - 23 hrs, 8 mins ago
more...

Page 3 of 9

< Prev

Next >

Last »

Thread Tools

fatalsaint	2010-01-12 , 15:21
Posts: 3,428 \| Thanked: 2,856 times \| Joined on Jul 2008	#21

Originally Posted by jaysire

Here's my df (diskfree) output. The parameter -h just means "human readable", which is Linux for "change bytes to megabytes and kilobytes and whatnot".
--snip--

So using your df output and the assumption that they are *partitions* and not separate flash memory...

Could it not be possible to delete the /home/user/MyDocs partition of 27GB and resize the /home partition to fill that space.. thus giving /opt the full 30+GB of available space for applications? Ext2/3 support resizing - I imagine since we're using symlinks at least / is ext2/3, what about /home? A small FAT partition could be used for the Camera (as I read that it won't work if a certain folder is ext2/3).

Also, symlinking /usr, /lib, and /var in the same way would also cause the rootfs to be virtually unused correct? It would be mostly a glorified boot partition with configuration files (/etc)? (Or mounting over existing /usr, /lib, and /var with the bind option to achieve the same effect?)

And for anybody wondering why the numbers don't add up to exactly 256MB or 32GB, it's because every filesystem type has overhead of it's own. When you format a drive in NTFS, FAT/32, Ext2, Ext3, etc - it uses a part of the space to store it's own information to know what all is going on with that partition. This is why the rootfs shows "227.9M" for example instead of 256.

__________________
If I've helped you or you use any of my packages feel free to help me out.
-----------------------------------------------------------------------------------
Maintaining:
pyRadio - Pandora Radio on your N900, N810 or N800!

Last edited by fatalsaint; 2010-01-12 at 15:24.

Quote & Reply |

Rob1n	2010-01-12 , 15:24
Posts: 3,617 \| Thanked: 2,412 times \| Joined on Nov 2009 @ Cambridge, UK	#22

You could do all that, yes. Remember that the rootfs is far quicker to access than the eMMC though, so anything moved will have a performance penalty.

Quote & Reply |

The Following 2 Users Say Thank You to Rob1n For This Useful Post:
fatalsaint, ossipena

	mankir	2010-01-12 , 15:30
	Posts: 276 \| Thanked: 224 times \| Joined on Dec 2009 @ Frankfurt, Germany	#23

How much is the performance penalty, when using /usr on eMMC? Because it solved the problem completely for me and is still useable, since ruskie posted the instructions!

Quote & Reply |

fatalsaint	2010-01-12 , 15:30
Posts: 3,428 \| Thanked: 2,856 times \| Joined on Jul 2008	#24

Originally Posted by Rob1n

You could do all that, yes. Remember that the rootfs is far quicker to access than the eMMC though, so anything moved will have a performance penalty.

~~So I guess where I was confused was the term "flash memory"... what is the onboard 256MB "flash memory" if the internal 32GB is MMC "flash memory"?~~

I see.. the 256MB is connected directly. What do you mean by "hi-speed" though... same ideal as the Speed Class ratings for MMC?

Quote & Reply |

SonicSpinner	2010-01-12 , 15:34
Posts: 16 \| Thanked: 10 times \| Joined on Jan 2010	#25

i got 86 mb free.

. ready for the big fw.

Quote & Reply |

Rob1n	2010-01-12 , 15:35
Posts: 3,617 \| Thanked: 2,412 times \| Joined on Nov 2009 @ Cambridge, UK	#26

It's all flash memory, just different types (and connected in different ways).

I've no idea what the actual performance penalty is - it's worth noting that the gtk-icon-cache removal in the latest firmware was done because it took up too much space on the rootfs but was too slow if moved to eMMC. It's probably not really an issue for individual files but is more likely to be noticed if lots of files need to be opened at the same time.

Quote & Reply |

texaslabrat	2010-01-12 , 16:47
Posts: 271 \| Thanked: 220 times \| Joined on Sep 2009	#27

Originally Posted by fatalsaint

So using your df output and the assumption that they are *partitions* and not separate flash memory...

Could it not be possible to delete the /home/user/MyDocs partition of 27GB and resize the /home partition to fill that space.. thus giving /opt the full 30+GB of available space for applications? Ext2/3 support resizing - I imagine since we're using symlinks at least / is ext2/3, what about /home? A small FAT partition could be used for the Camera (as I read that it won't work if a certain folder is ext2/3).

Yes, you could do that but then you would lose the ability to easily plug-n-pray with windows devices (though maybe you in particular don't care about that).

Also, symlinking /usr, /lib, and /var in the same way would also cause the rootfs to be virtually unused correct? It would be mostly a glorified boot partition with configuration files (/etc)? (Or mounting over existing /usr, /lib, and /var with the bind option to achieve the same effect?)

Not really an option due to the way that the system boots up and the order of operations in mounting the various volumes. I tried to move some stuff via symlink similar to how you suggested and it made the device unbootable. There is a utility floating around that will symlink pseudo-optify things on a per-application basis (using the apt-cache to figure out the necessary files and such) which will only move those things that are GUI-based (and thus not dependencies for booting).

And for anybody wondering why the numbers don't add up to exactly 256MB or 32GB, it's because every filesystem type has overhead of it's own. When you format a drive in NTFS, FAT/32, Ext2, Ext3, etc - it uses a part of the space to store it's own information to know what all is going on with that partition. This is why the rootfs shows "227.9M" for example instead of 256.

In addition to the formatting overhead, the difference between a "Megabyte" and a "Mebibyte" causes some of the discrepency

Storage is sold in the former, most computer systems/utilities (including df) use the latter.

Quote & Reply |

	RevdKathy	2010-01-12 , 19:08
	Posts: 2,173 \| Thanked: 2,678 times \| Joined on Oct 2009 @ Cornwall, UK	#28

I have 45.3 free - will I squeeze the new update under the wire?

(and will I get any more if I temporarily diable extras? - no, testing and devel are never enabled unless I open them to raid something on someone else's instruction!)

__________________
Hi! I'm Kathy and I'm a Maemo Greeter! Welcome.

Useful links for newcomers: New members say hello , New users start here, Community subforum, Beginners' wiki page, Maemo5 101, Frequently Asked Questions (FAQ)
Did you know Meego.com has forums too?

Quote & Reply |

texaslabrat	2010-01-12 , 20:19
Posts: 271 \| Thanked: 220 times \| Joined on Sep 2009	#29

Originally Posted by RevdKathy

I have 45.3 free - will I squeeze the new update under the wire?

(and will I get any more if I temporarily diable extras? - no, testing and devel are never enabled unless I open them to raid something on someone else's instruction!)

Well, going strictly by the "heads up" bulletin thing you should be OK. I would imagine it will come in less than 45 MB since they have told people to have 45 free (you always build in a little padding).

I don't think you'd free up much just by disabling a repository...I can't imagine the little db files taking up that much space. However, as I said before I don't think you're in trouble space-wise so long as you don't make it worse than it currently is

I wonder if there might be a simpler solution to all of this though. If the space is really just needed in order to download/unpack the files in preparation for installation...couldn't they just be downloaded into /opt by the update software? It's not like this is a performance-critical kind of thing we're dealing with. Just a random /ponder on my part.