Tiny Core Linux
Tiny Core Base => TCB Talk => Topic started by: bmarkus on June 25, 2009, 10:52:22 AM
-
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:
(http://tc.hasix.org/scrcap/ConkyTC20a.png)
Regards,
-
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.
-
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.
-
As a workaround, perhaps creating a wrapper for df could work (specificially targetting /) for those cases for now.
-
Yes, this is what I wanted to propose also as a workaround.
-
Just as an illustration, this is the output of df on SLAX6 when running in RAM:
(http://tc.hasix.org/scrcap/slaxramdf1.png)
-
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?
-
Yes, we can. The only question is the missing new dh command :) Will try to make one for testing next week.
-
I have built one and works for me.
I have posted for TC team testing before I make a public RC.
-
Thanks! Waiting to get it.
Béla
-
Robert,
thanks for the change in 2.1 Tested with Google Earth and its installer now sees properly the free space.
-
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.
-
I am very curious to know how this was solved. What file(s) were modified? Code snippet(s) of the relevant part(s)?
/Lars
-
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
-
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
-
Quoting the guru of initramfs, Rob Landley...
- When switching another root device, initrd would pivot_root and then
umount the ramdisk. But initramfs is rootfs: you can neither pivot_root
rootfs, nor unmount it. Instead delete everything out of rootfs to
free up the space (find -xdev / -exec rm '{}' ';'), overmount rootfs
with the new root (cd /newmount; mount --move . /; chroot .), attach
stdin/stdout/stderr to the new /dev/console, and exec the new init.
Since this is a remarkably persnickity process (and involves deleting
commands before you can run them), the klibc package introduced a helper
program (utils/run_init.c) to do all this for you. Most other packages
(such as busybox) have named this command "switch_root".
So I believe most memory should be reclaimed. The "extra" memory required during boot occurs while the copy takes place.
However, your idea is still interesting.
-
Thanks for pointing out the characteristics of switch_root.
Nice that you found my idea interesting :)
Looking at the kernel modules being part of the current rootfs, which ones do you see need to be available before tc-config executes? Which of the rootfs modules could be loaded during the current extension load performed by tc-config? Which modules needs to be loaded after tc-config start but before the current loading of extensions by tc-config?
As an example I guess the network driver modules needs to be loaded prior to starting the network (DHCP etc in tc-config), but maybe it would be possible for this case to reorder the code so that the network is not "started" unitil after tc-config has loaded the extensions?
A nice solution would be if one at the very beginning of tc-config could find out the path to the directory from where either the kernel or tinycore.gz where loaded from (typically both are loaded from the same directory) and from that very same directory load a file that contains the additional modules from today's rootfs. However I am not sure if it is possible to find this out, dou you have a clue? This file could for example be a tar or cpio (possibly gzipped) such that tc-config would load the modules to /lib/modules/...
/Lars
-
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 /)?
That's not true. Run switch_root without any arguments to get the help message:
Usage: switch_root [-c /dev/console] NEW_ROOT NEW_INIT [ARGUMENTS_TO_INIT]
Use from PID 1 under initramfs to free initramfs, chroot to NEW_ROOT, and exec NEW_INITThere's stated that initramfs will be freed.