[maemo-users] Not enough memory

[From: Eero Tamminen]

Hi,

ext Craig Woodward wrote:
> ---- Eero Tamminen <eero.tamminen at nokia.com> wrote: 
>> Compression can make normal ASCII data into 1/3 of its size
> 
> Yes, wonderful.  Is a default N900 using a compressed filesystem?
> NO. Why are we talking about it?  Moot point.

Err?

UBIFS used for rootfs is most certainly using compression.

For example the 20MB icon cache file (which is generated so it's
not in any package) that was earlier the largest issue for SSUs
(due to Gtk keeping old versions open) and which we removed for
PR1.1, took "only" 3MB of the rootfs space per instance.

Btw. In case you're interested, here are the technical details
which explain why even the file system itself cannot give very good
estimate on how much "free space" it has:
http://www.linux-mtd.infradead.org/doc/ubifs.html#L_spaceacc



>> And the issue with that is that package doesn't know into which Fremantle release it's going to be installed.
> 
> Doesn't the package manager send some kind of identifying info? 

Sorry, you lost me.

Where you're expecting this proposed package space estimation
to happen and when?  When creating a package?  Before installing it?
After it's installed?

If it's before install, what would provide that information to device?


[...]
> it's not saying it will take 17,367,483 bytes; it says "17.4M". 

Which I think is too accurate number when the things I mentioned
are taken into account. :-)


[..]
>> I think it's a bit too confusing to have on the Application Manager UI.
> 
> I disagree.  It think it's absolutely needed in the package manager,
> especially when the app manager is telling users "insufficient
> rootfs space" when trying to do PR updates.

/home is larger, but it can also run out of space.

Root running out of space is more important though because if it becomes
full (so that even root cannot write anything there), the system may not
anymore boot up.  /home partition becoming full means that applications
may not behave correctly (tracker cannot index new files, so media
player doesn't show them, email cannot be fetched etc).


> The app manager is the default tool they're going to use to install
> and remove packages.  Knowing how much space a package takes up on
> the rootfs is critical in selecting which packages to remove to make
> space for such an update.  Removing a non-optified 8M package is
> going to free a lot more space on the rootfs than removing an optified
> one that shows 60M of usage.  But you have to be able to tell if it's
> optified or not, which right now there's no way of telling.
 >
>> Maybe there could be a separate 3rd party application 
> 
> That would be great too, but having it in the app manager would make
> it that much easier.  It's one small piece of metadata, a few bytes
> per package.

Well, you're free to suggest such an UI change, but I have my doubts
about how well less-technical users understand the distinction between
rootfs and /home etc.  I assume you're suggesting that these values
would be shown in the UI always?


> Even if it's collected during install (doing a df
> pre/post and storing that per block device), it's something.

That would include also their dependencies, but those could be
shared between later installed packages.


> Nothing but the app manager can do that though, since it's the one
> doing the installs.  And really, nobody wants to hop from one app
> to the other to find/delete rootfs hogs.

And what about the non-UI packages that aren't shown in the Application
manager UI (for a good reason) and which also take space?

That hypothetical 3rd party application could show also those and
nothings preventing it from implementing package removal too.


	- Eero