maemo.org - Talk - Root space - What is "optifying"?

maemo.org - Talk (https://talk.maemo.org/index.php)

- Nokia N900 (https://talk.maemo.org/forumdisplay.php?f=44)

- - Root space - What is "optifying"? (https://talk.maemo.org/showthread.php?t=40131)

Quote:

Originally Posted by jaysire (Post 465259)

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.

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.

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:

Originally Posted by Rob1n (Post 466482)

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?

i got 86 mb free. :). ready for the big fw.

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:

Originally Posted by fatalsaint (Post 466474)

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).

Quote:

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).

Quote:

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.

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!)

Quote:

Originally Posted by RevdKathy (Post 466901)

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.

Quote:

Originally Posted by wmarone (Post 465268)

I think you mean 85% used (15% available.)

Darn it, thought I fixed all my careless mistakes already. :) Thanks for the heads up.