Tiny Core Base > TCB Q&A Forum
Understanding tc: Why is “mount on boot” not super fast?
Stefann:
Hi,
Sorry if this common knowledge or if it is already described somewhere.
I’m trying to learn.
At this moment I have several apps installed as “mount at boot”. I DO understand that I could have chosen for “on demand” which would save mount time and maybe I will do that. At this moment I just want to understand.
What I see happening during startup is that the time spend “mounting all those packages” takes quite some time (I did not time it exactly but I guess 30..60 seconds).
In my (ignorant) assumption “mounting” is just setting some pointers and does not really actively “do” something. After all… the whole reason “not to choose copy mode” is to avoid taking time to load them in ram. If that is the case mounting of all applications together should take less than a second.
For that reason my question: “why is it taking considerable time”? And/or “any smart thoughts about the philosophy behind things” (because this choice between “on demand”/“on boot”/“copy” I consider a very core aspect of TC, i would not be surprised if there would be an untold “philosophy”/“deeper thought” on this).
Note. Practically speaking the boot time is no problem at all. I use tc as os behind a 24/7 home control computer. I boot it only in case of some maintenance. It’s just curiosity.
curaga:
The book contains a lot of info on this, on why symlinks vs unionfs etc.
Stefann:
--- Quote from: curaga on August 24, 2024, 02:29:46 AM ---The book contains a lot of info on this, on why symlinks vs unionfs etc.
--- End quote ---
Thanks, I needed that pointer.
I had read the book already once but “message did not compute at that time”.
The “unionfs” pointer helpt me locating the chapter.
Please be aware I’m not a Linux expert. I’m learning.
I’m highly intrigued and impressed by the tiny core approach though. It is quite brilliant.
- the frugal approach keeps the os clean.
- the .filetool.lst file contains a highly transparent and simple overview of user modifications to the os.
- all in ram makes it super fast and keeps the flashdrive alive by not writing to it (unless specifically asked by the user application)
Stefann:
Ok… I studied the book “with red ears”.. wow :)
I guess the answer to my question is:
- the tgz is a squashfs based compressed filesystem.
- on boot it creates several mount points in the main filesystem.
- squashfs needs “few blocks in ram” to do that.
So the time is consumed in:
- creating the several mount points in the main filesystem to begin with
- inserting the squashhfs overhead in ram needed to efficiently “make this work”
The method “maintains the original filestructure” of the application (which is good because the os than not generates unexpected omissions).
But that also means that complex applications (such as the gcc compiler) need some time to get mounted IF they need a lot of mountpoints.
>> makes perfect sense! Happy to have learned this.
(Including having broadened my general Linux knowledge)
CentralWare:
--- Quote from: Stefann on August 24, 2024, 01:13:40 AM ---What I see happening during startup is that the time spend “mounting all those packages” takes quite some time (I did not time it exactly but I guess 30..60 seconds).
--- End quote ---
@Stefann: Good morning!
It sounds to me as though you have a desktop environment and quite a few extensions loading during boot.
If boot time were a concern, you can delegate some extensions to load AFTER the desktop launches.
For example, let's say you had OpenSSH or Dropbear loading to give you remote shell access to the machine. This doesn't HAVE to be something that's done right this second while it's booting up as it'll delay getting to the desktop and it has nothing to DO with the desktop's operations. That said, you could take OpenSSH out of /etc/sysconfig/tcedir/onboot.lst and instead, load it later... in the background... after your desktop is finished and operational.
The extensions you take out of onboot.lst... move them into onlater.lst in the same location. onlater.lst is just a name I came up with, it is not in the TCL text book.
Do not add drivers/firmware, Xorg support extensions or file systems to onlater.lst as it may have adverse results or even stop the desktop from loading.
Add a new line somewhere near the end of /opt/bootlocal.sh
--- Code: ---/opt/bootlater.sh &
--- End code ---
Then create /opt/bootlater.sh
--- Code: ---#!/bin/sh
TCEDIR=/etc/sysconfig/tcedir
for EXT in $(cat $TCEDIR/onlater.lst)
do
su -c "tce-load -i ${TCEDIR}/optional/${EXT}" tc
sleep 1
done
--- End code ---
Run backup if you are using backup to persist your changes so that /opt/bootlater.sh gets saved.
The extensions you load in the background, I would recommend limiting any extensions that add icons to the toolbar/wbar/etc. as too many of these being done at the same time can get odd results.
The sleep() call above slows down loading extensions in the background to help prevent some of these oddities.
--- Quote from: Stefann on August 24, 2024, 04:31:51 AM ---Please be aware I’m not a Linux expert. I’m learning.
--- End quote ---
That is exactly why we do what we do here...
Navigation
[0] Message Index
[#] Next page
Go to full version