Free partition space when running in RAM

[bmarkus]

Dear Core Team,

just one thought for TC 2.1 features.

There are applications not available in source as usual but come with their own installer, like Google Earth and few others. These are checking available free free space in certain directoriesl, like /opt, ~, etc. and find 0 available when TC is running in RAM. There are other cases also where frree / available 'partition' size mybe interesting and would be good to have available on a usual LINUX way.

As an example see Conky reporting 0 space:



Regards,

[Lee]

I saw this with the gtm5 extension where the mupip utility would not create a database file in ~tc (in ram) because it detected zero free space.  I thought at the time it was a problem with mupip and worked around it by creating a database file on a physical disk filesystem, moving the file to ~tc and saving it (compressed) as part of the .tce (to be installed by the startup script if not already present).

An empty database compresses really well, but I could still shave a few KB off of the .tce if I could just create the database on the fly when needed.

[roberts]

TC is running as an embedded system, i.e., we stay running in initramfs. Typically all 2.6 based systems will have a small initramfs which is used until switch to a mounted root fs. Therefore initramds is ignored by df command. There was much debate if df should display it as it would be confusing to typical non-embedded use. We can monitor busybox, which promotes initramfs use, to see if initramfs df detection will be implemented. Interesting that Rob Landley, a major busybox developer, did make a  change to df in toybox's df command to report on initramfs.

[^thehatsrule^]

As a workaround, perhaps creating a wrapper for df could work (specificially targetting /) for those cases for now.

[bmarkus]

Yes, this is what I wanted to propose also as a workaround.

[bmarkus]

Just as an illustration, this is the output of df on SLAX6 when running in RAM:

[roberts]

That would seem to indicate that a tmpfs was setup with a targeted size.
As a work around, for those that need it,  could you not do the same?

[bmarkus]

Yes, we can. The only question is the missing new dh command  Will try to make one for testing next week.

[roberts]

I have built one and works for me.
I have posted for TC team testing before I make a public RC.

[bmarkus]

Thanks! Waiting to get it.

Béla

[bmarkus]

Robert,

thanks for the change in 2.1 Tested with Google Earth and its installer now sees properly the free space.

[roberts]

There is a small price to pay, both in boot time and memory usage.
At first I was relucant to do it, but now I think it was worth doing.

[helander]

I am very curious to know how this was solved. What file(s) were modified? Code snippet(s) of the relevant part(s)?


/Lars

[roberts]

initramfs, which has served us well, does not have a specified size, therefore df reports 0 and installation scripts that check space requirements fail.

tmpfs which also is ram based can easily be setup with size specified.

Therefore it is easy to setup tmpfs and copy the contents of initramfs to tmpfs and switch root to tmpfs.

The setup, copy, and switch root, is the price to pay to use tmpfs over initramfs. You can easily see how I solved this by looking at the contents of /init

[helander]

You can easily see how I solved this by looking at the contents of /init

Thanks.

I failed to look at all places, except the obvious  .

With this solution, I guess the memory used for the initramfs is not reclaimed (guess based on no explicit unmount in the init script and that mount command shows a rootfs mounted at /)?

Could this memory be reclaimed at all? Since init runs from this filesystem I guess it could be hard to dispose of it?

If the memory can not be reclaimed, one could possible improve the memory situation by a scheme like the following:

   

• build the drivers for filesystems and other elements used short after boot into the kernel
• load rest of the modules currently in tinycore.gz thru an extension during tc-config

Since the loading of extensions are made fairly "late" in tc-config, some re-ordering of the stuff in tc-config might be needed.

This would make tinycore.gz "free" from kernel modules and make the non-reclaimable memory portion smaller (smaller initramfs).

Another benefit of this solution is for people like myself that uses tinycore with a custom kernel. This way one could use the standard tinycore.gz with "any" kernel, since all things needed before tc-config would be in the kernel and the rest of the stuff will be thru an extension that is built for that particular kernel and loaded by tc-config.


/Lars